Bug 1451321 - libvncserver blocks gtk-vnc clients >= 0.7.0
Summary: libvncserver blocks gtk-vnc clients >= 0.7.0
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libvncserver
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-05-16 11:50 UTC by Jonathan Dieter
Modified: 2017-06-03 17:38 UTC (History)
2 users (show)

Fixed In Version: libvncserver-0.9.11-2.fc25.1 libvncserver-0.9.11-2.fc26
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-26 04:03:39 UTC


Attachments (Terms of Use)
Patch to allow clients to send "RFB " string directly on connection (1.23 KB, application/mbox)
2017-05-16 11:50 UTC, Jonathan Dieter
no flags Details

Description Jonathan Dieter 2017-05-16 11:50:33 UTC
Created attachment 1279308 [details]
Patch to allow clients to send "RFB " string directly on connection

libvncserver currently blocks any clients that send the first part of the protocol negotiations before the server sends their negotiation.  Gtk-vnc-0.7.0 has started sending the first four bytes ("RFB ") before the server sends its negotiations to fix problems when accidentally connecting to SPICE servers (see https://git.gnome.org/browse/gtk-vnc/commit/?id=7f4f2fe for more details).

I've written a small patch that fixes this problem by allowing clients to send the first four bytes (which should always be "RFB ") before the server sends its negotiations.

Comment 1 Jonathan Dieter 2017-05-16 11:52:48 UTC
This patch fixes bug #1421785, but I didn't want to take that bug over as I'm not sure if my approach is what the OP is looking for.

Comment 2 Jonathan Dieter 2017-05-16 11:54:07 UTC
This patch also applies cleanly to 0.9.10 and 0.9.11, and, if possible, should be backported to F25 and F26 as they both have had an update to gtk-vnc-0.7.0.

Upstream pull request for this patch is at https://github.com/LibVNC/libvncserver/pull/179

Comment 3 Rex Dieter 2017-05-16 15:03:38 UTC
I'm tempted to wait for upstream feedback on the pull request before applying downstream at least.

On the other hand, if you think the risk is minimal applying anyway, feel free to do so.

Comment 4 Jonathan Dieter 2017-05-16 15:08:44 UTC
Yeah, apparently upstream has already fixed the issue almost identically to my fix at https://github.com/LibVNC/libvncserver/commit/75f04c14e49e084e41bdd5491edad8823773a08c

Since that patch is upstream and the risk is minimal, I'll go ahead and apply it then.

Comment 5 Rex Dieter 2017-05-16 15:13:26 UTC
actually, looks like there's an outstanding CVE issue open against libvncserver too, so I'll take the liberty of pulling in both fixes I guess.

Comment 6 Jonathan Dieter 2017-05-16 15:14:04 UTC
Ok, great!  Thanks so much.

Comment 7 Fedora Update System 2017-05-16 16:54:15 UTC
libvncserver-0.9.11-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-6125002d79

Comment 8 Fedora Update System 2017-05-16 16:55:44 UTC
libvncserver-0.9.11-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-0e08170fd3

Comment 9 Fedora Update System 2017-05-16 16:57:52 UTC
libvncserver-0.9.11-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-dd5d2381e4

Comment 10 Jonathan Dieter 2017-05-17 05:10:44 UTC
Hey Rex, just a heads up that 0.9.11 has a soname bump from 0.9.10, so it's probably not a good idea to update F24 and F25 to 0.9.11.  My plan was to apply the upstream patch to 0.9.10 for F24 and F25.

Comment 11 Jonathan Dieter 2017-05-17 05:23:19 UTC
Having looked at this closer, it looks like a symbol was removed in 0.9.9, but the soname wasn't bumped until 0.9.11.  I'm guessing a rebuild of all the dependent packages against 0.9.11 should fix everything, but I'm not sure if a soname bump goes against the updates policy, even if there are no backwards-incompatible ABI changes.

Comment 12 Petr Pisar 2017-05-17 05:32:35 UTC
Yes, it goes. People have software built locally or from foreign repositories.

Comment 13 Jonathan Dieter 2017-05-17 06:06:07 UTC
In this case, where there's no actual ABI changes (I'm looking at https://abi-laboratory.pro/tracker/timeline/libvncserver/) to go with the soname bump, would it make sense to do a symlink from libvncserver.so.0 to libvncserver.so.1 *only* for F24 and F25?

Or would it be better to pull these updates and backport the CVE fixes to 0.9.10?

Comment 14 Rex Dieter 2017-05-17 14:12:51 UTC
Sorry I didn't realize there was a soname bump here.  Symlinks are not a solution for that.

That said, there are other fixes I'd like to get included for f24/f25 updates, not just this one, so I'd rather persue rebuilding dependencies if possible.

Comment 15 Rex Dieter 2017-05-17 14:17:49 UTC
In the meantime, I'll revoke the existing f25/f24 bodhi updates at earliest opportunity (apparently I can't right now, I assume the update is locked for an ongoing push).

Comment 16 Rex Dieter 2017-05-17 14:20:24 UTC
Re-reading comments, comment #11 in particular, at least strongly implies that 0.9.9 and 0.9.10 should be ABI compatible with 0.9.11.  If that is the case, I think one option would be to simply revert the soname change for f24/f25 updates (back to .0).  Thoughts?

Comment 17 Jonathan Dieter 2017-05-17 15:14:17 UTC
(In reply to Rex Dieter from comment #16)
> Re-reading comments, comment #11 in particular, at least strongly implies
> that 0.9.9 and 0.9.10 should be ABI compatible with 0.9.11.  If that is the
> case, I think one option would be to simply revert the soname change for
> f24/f25 updates (back to .0).  Thoughts?

I'd prefer that option over rebuilding dependencies with .1 as RPM Fusion has some packages as well that depend on this (vlc comes to mind).

0.9.10 has no ABI symbol changes from 0.9.9, and 0.9.11 has one added symbol compared to 0.9.10.  One of the structs has added a field between 0.9.9 and 0.9.10 and then an additional two fields between 0.9.10 and 0.9.11, but as I understand it, that doesn't break backwards compatibility.

We're at the end of the day here, but tomorrow I'll go ahead build 0.9.11 with a .0 soname and see whether it breaks vlc or x11vnc.

Comment 18 Rex Dieter 2017-05-17 16:33:57 UTC
I did just that, and tested a few apps (krfb, krdc, vlc), and no *obvious* problems, so,

https://src.fedoraproject.org/cgit/rpms/libvncserver.git/commit/?id=46fa05c99237813c26dc60a81fa847ad1cc9eab9

Comment 19 Fedora Update System 2017-05-17 19:07:56 UTC
libvncserver-0.9.11-2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-6125002d79

Comment 20 Fedora Update System 2017-05-17 23:07:27 UTC
libvncserver-0.9.11-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-dd5d2381e4

Comment 21 Fedora Update System 2017-05-17 23:12:15 UTC
libvncserver-0.9.11-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-0e08170fd3

Comment 22 Jonathan Dieter 2017-05-18 05:35:07 UTC
I've just built 2.fc25.1 and it's working great with x11vnc.  Once it ends up in bodhi, I'll add karma.

Comment 23 Fedora Update System 2017-05-18 13:09:38 UTC
libvncserver-0.9.11-2.fc25.1 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-0e08170fd3

Comment 24 Fedora Update System 2017-05-18 13:10:08 UTC
libvncserver-0.9.11-2.fc24.1 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-dd5d2381e4

Comment 25 Fedora Update System 2017-05-18 23:30:19 UTC
libvncserver-0.9.11-2.fc24.1 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-dd5d2381e4

Comment 26 Fedora Update System 2017-05-18 23:34:50 UTC
libvncserver-0.9.11-2.fc25.1 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-0e08170fd3

Comment 27 Rex Dieter 2017-05-25 12:27:46 UTC
FYI, also gtk-vnc upstream implemented a fix/workaround as well, see also:
https://git.gnome.org/browse/gtk-vnc/commit/?id=f5623cbc63bb0a835bc662d451cc5128d683bd5d

Comment 28 Fedora Update System 2017-05-26 03:54:57 UTC
libvncserver-0.9.11-2.fc24.1 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 29 Fedora Update System 2017-05-26 04:03:39 UTC
libvncserver-0.9.11-2.fc25.1 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 30 Fedora Update System 2017-06-03 17:38:52 UTC
libvncserver-0.9.11-2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.


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