Bug 1416692

Summary: spice server should drop clients immediately after receiving incorrect magic bytes
Product: Red Hat Enterprise Linux 7 Reporter: Daniel Berrangé <berrange>
Component: spiceAssignee: Default Assignee for SPICE Bugs <rh-spice-bugs>
Status: CLOSED ERRATA QA Contact: SPICE QE bug list <spice-qe-bugs>
Severity: low Docs Contact:
Priority: low    
Version: 7.0CC: berrange, cfergeau, cwei, dblechte, desktop-qa-list, fidencio, gkong, jjongsma, mjenner, mzhan, rbalakri, rduda, tpelka, tzheng
Target Milestone: rc   
Target Release: 7.4   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: spice-0.12.8-2.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 921330 Environment:
Last Closed: 2017-08-01 16:06:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 921330    

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