[Qemu-devel] SPICE session's connection_id's are not unique

[Qemu-devel] SPICE session's connection_id's are not unique

[Michael Tokarev]

Forwarding to qemu-devel@ from http://bugs.debian.org/920897

Thanks,

/mjt

-------- Forwarded message --------
Subject: 	Bug#920897: SPICE session's connection_id's are not unique
Date: 	Wed, 30 Jan 2019 11:21:54 +0000
From: 	Philip Pum <Philip.Pum@radarservices.com>


Package: qemu-system-x86
Version: 1:2.8+dfsg-6+deb9u4


When creating a virtual machine with qemu (e.g. via libvirt) including a SPICE server, the client_id of the SPICE session is not unique. For example, starting multiple virtual machines on the same libvirtd, the client_id is the same for all virtual machine's SPICE sessions.


A description of the client_id can be found in

https://www.spice-space.org/static/docs/spice_protocol.pdf under section 2.11. c) :


"UINT32 connection_id - In case of a new session (i.e., channel type is RED_CHANNEL_MAIN) this field is set to zero, and in response the server will allocate session id and will send it via the RedLinkReply message. In case of all other channel types, this field will be equal to the allocated session id"


The relevant code for generating client ids in libspice-server1 can be found here: https://gitlab.freedesktop.org/spice/spice/blob/v0.12.8/server/reds.c#L1614

This uses rand() to generate the random id, but qemu (at least in the case of qemu-system-x86) fails to initialize the RNG seed (with e.g. srand()).


The result is, that every SPICE session started (by e.g. libvirtd) has the same client_id. Usually, this is not a problem, but running something like a SPICE proxy, relying on the client_id to correctly route connections, this creates problems.


Adding something like 'srand(time(NULL));' to qemu (in vl.c) solves this issue. Related (as seen in some VNC patches, e.g. 'CVE-2017-15124/04-ui-avoid-pointless-VNC-updates-if-framebuffer-isn-t-.patch/ui/vnc.c' ):  srand(time(NULL)+getpid()+getpid()*987654+rand());


Tested on Debian 9.7 with kernel  4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux.

Re: [Qemu-devel] SPICE session's connection_id's are not unique

[Daniel P. Berrangé]

On Wed, Jan 30, 2019 at 06:29:04PM +0300, Michael Tokarev wrote:
> Forwarding to qemu-devel@ from http://bugs.debian.org/920897
> 
> Thanks,
> 
> /mjt
> 
> -------- Forwarded message --------
> Subject: 	Bug#920897: SPICE session's connection_id's are not unique
> Date: 	Wed, 30 Jan 2019 11:21:54 +0000
> From: 	Philip Pum <Philip.Pum@radarservices.com>


> When creating a virtual machine with qemu (e.g. via libvirt) including a SPICE server,
> the client_id of the SPICE session is not unique. For example, starting multiple
> virtual machines on the same libvirtd, the client_id is the same for all virtual
> machine's SPICE sessions.
> 
> 
> A description of the client_id can be found in
> 
> https://www.spice-space.org/static/docs/spice_protocol.pdf under section 2.11. c) :
> 
> 
> "UINT32 connection_id - In case of a new session (i.e., channel type is RED_CHANNEL_MAIN)
>  this field is set to zero, and in response the server will allocate session id and will
>  send it via the RedLinkReply message. In case of all other channel types, this field 
>  will be equal to the allocated session id"

IIUC, that is just claiming that connection_id will be unique within the
scope of clients connected to a single SPICE server.

> The relevant code for generating client ids in libspice-server1 can be
> found here: https://gitlab.freedesktop.org/spice/spice/blob/v0.12.8/server/reds.c#L1614
> 
> This uses rand() to generate the random id, but qemu (at least in the
> case of qemu-system-x86) fails to initialize the RNG seed (with e.g. srand()).
> 
> The result is, that every SPICE session started (by e.g. libvirtd) has
> the same client_id. Usually, this is not a problem, but running something
> like a SPICE proxy, relying on the client_id to correctly route connections,
> this creates problems.

Presumably this means s/client_id/connection_id/ here given the quote
3 paragraphs earlier.

Each QEMU process has its own SPICE server, so the SPICE protocol spec
above does not guarantee that cconnection_id  is unique between
different QEMU process - only unique within multiple connections to
a single QEMU process, which I think is achieved even with the missing
srand() call.

Distinguishing different clients is a security critical task for a
SPICE proxy. I'm not sure I'd be comfortable with security of relying
on the 32-bit integer identifier to be unique across every SPICE server
in every QEMU when there are 100's of VMs on a host, even if QEMU did
call srand() correctly.

None the less, I'd suggest that spice server stop usin rand() entirely.
It already links to openssl, so I'd suggest they request a random value
from openssl which can provide cryptographically strong random values.

> Adding something like 'srand(time(NULL));' to qemu (in vl.c) solves this
> issue. Related (as seen in some VNC patches, e.g.
> 'CVE-2017-15124/04-ui-avoid-pointless-VNC-updates-if-framebuffer-isn-t-.patch/ui/vnc.c' ):  srand(time(NULL)+getpid()+getpid()*987654+rand());

We should probably move the srand() call into vl.c in QEMU. At the same
time though, we should initialize it with a cryptoraphically strong
input we get from qcrypto_random_bytes(). Again though, we should purge
any code which uses rand() from QEMU, in favour of using qcrypto_random_bytes
directly as that#s backed by a cryptographically strong source.

Fortnuately this use of rand() is not a security issue for VNC, since
the VNC authentication scheme is already fundamentally broken by
design and should never be used. The VNC TLS + SASL extensions
provide a real auth scheme for VNC.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|