linux-kernel - Re: [PATCH 1/3] xen: xenbus driver must not accept invalid transaction ids

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 22 Dec 2016 16:51:52 +0100
From:   Juergen Gross <jgross@...e.com>
To:     Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        linux-kernel@...r.kernel.org, xen-devel@...ts.xenproject.org
Subject: Re: [PATCH 1/3] xen: xenbus driver must not accept invalid
 transaction ids

On 22/12/16 16:38, Boris Ostrovsky wrote:
> On 12/22/2016 02:19 AM, Juergen Gross wrote:
>> When accessing Xenstore in a transaction the user is specifying a
>> transaction id which he normally obtained from Xenstore when starting
>> the transaction. Xenstore is validating a transaction id against all
>> known transaction ids of the connection the request came in. As all
>> requests of a domain not being the one where Xenstore lives share
>> one connection, validation of transaction ids of different users of
>> Xenstore in that domain should be done by the kernel of that domain
>> being the multiplexer between the Xenstore users in that domain and
>> Xenstore.
>>
>> In order to prohibit one Xenstore user to be able to "hijack" a
>> transaction from another user the xenbus driver has to verify a
>> given transaction id against all known transaction ids of the user
>> before forwarding it to Xenstore.
>>
>> Signed-off-by: Juergen Gross <jgross@...e.com>
> 
> 
> Should this go to stable trees as well?

I don't think it is necessary. First I thought this could be a security
problem, but any user who could make use of that problem could easily
trash complete Xenstore, so there are no additional security concerns
with this "bug" not being handled.

After all it is just a matter of avoiding problems due to buggy Xenstore
users which are probably not existing at all. :-)

> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@...cle.com>

Thanks,

Juergen