Skip to content

SPICE session's connection_id's are not unique

This bug has been copied automatically from: https://bugs.launchpad.net/qemu/+bug/1815371
Reported by 'Laurent Bigonville' on 2019-02-10 :

From: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920897

=====

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.



=====
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information