Bug 1416692 - spice server should drop clients immediately after receiving incorrect magic bytes
Summary: spice server should drop clients immediately after receiving incorrect magic ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: spice
Version: 7.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: 7.4
Assignee: Default Assignee for SPICE Bugs
QA Contact: SPICE QE bug list
URL:
Whiteboard:
Depends On:
Blocks: 921330
TreeView+ depends on / blocked
 
Reported: 2017-01-26 09:28 UTC by Daniel Berrangé
Modified: 2017-08-01 16:06 UTC (History)
14 users (show)

Fixed In Version: spice-0.12.8-2.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 921330
Environment:
Last Closed: 2017-08-01 16:06:08 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:1866 0 normal SHIPPED_LIVE spice bug fix and enhancement update 2017-08-01 17:52:34 UTC

Description Daniel Berrangé 2017-01-26 09:28:45 UTC
When used with QEMU at least, both SPICE and VNC live in the same port
range (5900+). It is thus not entirely uncommon for a user to mistakenly
connect to a SPICE server with a VNC client, or vica-verca.

When connecting to VNC server with a SPICE client, you quickly get an
error. This is because the VNC server sends its short greeting and then
sees the RedLinkMess from the SPICE client, realizes its garbage and
drops the connection.

When connecting to a SPICE server with a VNC client though, you get an
indefinite hang. The VNC client is waiting for the VNC greeting, which
the SPICE server will never send. The SPICE server is waiting for the
RedLinkMess which the VNC client will never send.

In VNC the protocol starts with the follow data sent:

 Server: "RFB 003.008\n"
 Client: "RFB 003.008\n"

The GTK-VNC client is going to be changed such that it does

 Client: "RFB "
 Server: "RFB 003.008\n"
 Client: "003.008\n"

From the VNC server POV, it'll still be receiving the same 12 bytes from
the client - it just happens that 4 of them might arrive a tiny bit
earlier than the other 8 of them. IOW nothing should break in the VNC
server from this change.

Now the SPICE server is waiting to receive RedLinkMess, the first 4
bytes of which are a magic number. Upon a (modified) VNC client connecting 
it will receive "RFB " as the magic number, The SPICE should check this
magic number and drop the bogus connection, before waiting for the rest of
the RedLinkMess message to arrive.

This is implemented by this paach:

https://lists.freedesktop.org/archives/spice-devel/2017-January/035211.html

Comment 1 Daniel Berrangé 2017-01-26 09:36:19 UTC
FYI this bug is a pre-requisite to make the corresponding VNC client fix actually work (see  https://bugzilla.redhat.com/show_bug.cgi?id=921330 )

Comment 3 Jonathon Jongsma 2017-02-01 17:50:28 UTC
The mentioned patch is now upstream.

Comment 4 Frediano Ziglio 2017-02-27 22:50:55 UTC
Should this goes into 7.4 ?

Comment 5 Daniel Berrangé 2017-02-28 10:05:55 UTC
(In reply to Frediano Ziglio from comment #4)
> Should this goes into 7.4 ?

Yes, the corresponding gtk-vnc fix is in 7.4

Comment 6 Christophe Fergeau 2017-04-25 08:40:33 UTC
Moving back to POST, the patch is not in a build yet.

Comment 9 errata-xmlrpc 2017-08-01 16:06:08 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1866


Note You need to log in before you can comment on or make changes to this bug.