Bug 25918 - libvncserver new security issue CVE-2019-15690
Summary: libvncserver new security issue CVE-2019-15690
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
Whiteboard: MGA7-64-OK
Keywords: advisory, validated_update
Depends on:
Reported: 2019-12-20 22:03 CET by David Walser
Modified: 2020-04-15 12:13 CEST (History)
7 users (show)

See Also:
Source RPM: libvncserver-0.9.12-2.1.mga7.src.rpm
Status comment:


Description David Walser 2019-12-20 22:03:07 CET
A security issue discovered in libvncserver has been mentioned here:

There doesn't appear to be a fix available yet.

Mageia 7 is also affected.
David Walser 2019-12-20 22:03:15 CET

Whiteboard: (none) => MGA7TOO

Comment 1 Lewis Smith 2019-12-21 20:40:55 CET
No registered maintainer, so assigning yet again to DavidG since you have been the actual committer of updates for this package.
Re-assign it to pkg-bugs if this is too much. Time to breath at least:
> There doesn't appear to be a fix available yet

Assignee: bugsquad => geiger.david68210

Comment 2 David Walser 2020-03-18 13:43:02 CET
Debian-LTS has issued an advisory for this today (March 18):

Status comment: (none) => Patches available from Debian and upstream

Comment 3 David GEIGER 2020-03-19 06:12:33 CET
Done for both Cauldron and mga7!
Comment 4 David Walser 2020-03-19 11:24:22 CET

Updated libvncserver packages fix security vulnerability:

In libvncserver, through libvncclient/cursor.c, there is a possibility of a
heap overflow, as reported by Pavel Cheremushkin (CVE-2019-15690).


Updated packages in core/updates_testing:

from libvncserver-0.9.12-2.2.mga7.src.rpm

CC: (none) => geiger.david68210
Version: Cauldron => 7
Status comment: Patches available from Debian and upstream => (none)
Whiteboard: MGA7TOO => (none)
Assignee: geiger.david68210 => qa-bugs

Comment 5 Herman Viaene 2020-03-20 12:07:33 CET
MGA7-64 Plasma on Lenovo B50
No installation issues.
Installed x11vnc , run this on the laptop defining a password.
Try to connet from desktop using the vncviewer as in bug 25788. I get response from the laptop in the way that the question comes to input the password. Then I get the dreaded box: "Invalid display size".
That has prevented me in the past to ever use teigervncserver successfully, but x11vnc never presented this problem up to now. Running out of options.

CC: (none) => herman.viaene

Comment 6 Len Lawrence 2020-04-09 23:14:56 CEST
mga7, x86_64

No better here Herman.
$ x11vnc -display :0
on the remote machine where a password has been stored.

On the local machine:
$ vncviewer -DesktopSize=2560x1440 belexeuli:0
 CConn:       Connected to host belexeuli port 5900
 CConnection: Server supports RFB protocol version 3.8
 CConnection: Using RFB protocol version 3.8
 CConnection: Choosing security type None(1)
 CConn:       Invalid display size

Does not ask for password.

Beats me.

CC: (none) => tarazed25

Comment 7 Len Lawrence 2020-04-09 23:21:28 CEST
Continuing from comment 6:

At the remote end x11vnc logs this before exiting:

09/04/2020 22:13:17 Got connection from client 192.168.1.abc
09/04/2020 22:13:17   other clients:
09/04/2020 22:13:18 Normal socket connection
09/04/2020 22:13:18 Disabled X server key autorepeat.
09/04/2020 22:13:18   to force back on run: 'xset r on' (3 times)
09/04/2020 22:13:18 incr accepted_client=1 for 192.168.1.abc:51020  sock=10
09/04/2020 22:13:18 Client Protocol Version 3.8
09/04/2020 22:13:18 Protocol version sent 3.8, using 3.8
09/04/2020 22:13:18 rfbProcessClientSecurityType: executing handler for type 1
09/04/2020 22:13:18 rfbProcessClientSecurityType: returning securityResult for client rfb version >= 3.8
09/04/2020 22:13:18 copy_tiles: allocating first_line at size 81
09/04/2020 22:13:18 client_count: 0
09/04/2020 22:13:18 Restored X server key autorepeat to: 1
09/04/2020 22:13:18 viewer exited.
09/04/2020 22:13:18 deleted 80 tile_row polling images.
Comment 8 David Walser 2020-04-09 23:23:53 CEST
What if you don't use the DesktopSize argument?  Is it a regression?
Comment 9 Len Lawrence 2020-04-10 00:15:13 CEST
With or without the DesktopSize argument the result is the same.

vncviewer asked for the password, which it accepted, then crashed out on "Invalid display size".
I have no idea if this is a regression because I do not remember it ever working.
It certainly did not before the update.

At the remote end:
$ x11vnc -rfbauth .vnc/passwd -display :0
The VNC desktop is:      belexeuli:0
09/04/2020 22:55:28 Got connection from client 192.168.1.abc
09/04/2020 22:55:28   other clients:
09/04/2020 22:55:28 Normal socket connection
09/04/2020 22:55:28 Disabled X server key autorepeat.
09/04/2020 22:55:28   to force back on run: 'xset r on' (3 times)
09/04/2020 22:55:28 incr accepted_client=1 for 192.168.1.abc:51100  sock=10
09/04/2020 22:55:28 Client Protocol Version 3.8
09/04/2020 22:55:28 Protocol version sent 3.8, using 3.8
09/04/2020 22:55:28 rfbProcessClientSecurityType: executing handler for type 2
09/04/2020 22:55:29 created   xdamage object: 0x4200054
09/04/2020 22:55:29 copy_tiles: allocating first_line at size 81
09/04/2020 22:55:38 created selwin: 0x4200055
09/04/2020 22:55:38 called initialize_xfixes()
09/04/2020 22:55:41 client_count: 0
09/04/2020 22:55:41 Restored X server key autorepeat to: 1
09/04/2020 22:55:41 viewer exited.
09/04/2020 22:55:41 deleted 80 tile_row polling images.
Comment 10 David Walser 2020-04-10 00:31:52 CEST
I think the invalid display size error was from another package (tigervnc, which is where the vncviewer comes from), so you can OK this one.
Comment 11 Len Lawrence 2020-04-10 01:13:49 CEST
Running tigervnc-1.10.1-1.mga7 here, noting that in earlier reports of vncviewer problems it was necessary to downgrade tigervnc to avoid invalid display size. 

Maybe there are other viewers we can use which depend on libvncserver?
Comment 12 Len Lawrence 2020-04-10 01:28:19 CEST
Could not find any.  remmina does not appear to use libvncserver.
@Herman: my tests  were the same as yours essentially.  David recommends we pass this on.  Adding the OK.

Whiteboard: (none) => MGA7-64-OK

Comment 13 David Walser 2020-04-10 01:29:43 CEST
What about linuxvnc or remmina?
Comment 14 Len Lawrence 2020-04-10 01:47:27 CEST
Have installed linuxvnc.  Shall try it out later - need sleep.
Comment 15 Len Lawrence 2020-04-10 10:28:52 CEST
Giving up on linuxvnc.  It seems to be more about exporting TTYs, and the documentation looks ancient.  There is no man page for it unless you go online.
It looks like it can be run without arguments which implies that it should be at the remote end.
$ linuxvnc
10/04/2020 09:08:36 Couldn't open tty device /dev/tty2!
$ linuxvnc belexeuli:0
10/04/2020 09:11:23 Usage: linuxvnc [tty_number [vnc args]]
$ linuxvnc 1 belexeuli:0
10/04/2020 09:12:31 Couldn't open tty device /dev/tty1!
lcl@difda:~ $ who
lcl      tty1         2020-04-08 23:13 (:0)

Does not look like a viewer anyway.
Comment 16 David GEIGER 2020-04-10 10:39:38 CEST
remmina-plugins-vnc uses libvncserver.
Comment 17 Len Lawrence 2020-04-10 10:46:34 CEST
Yeah, thanks David.  I had just discovered that:
"Correction regarding remmina.  remmina-plugins-vnc does need the library.
Installing remmina-plugins-vnc."
Comment 18 Len Lawrence 2020-04-10 11:27:59 CEST
Logged out and in and ran remmina which presented a gui.  Tried an ssh connection.  That worked, same as using ssh from the command line.  VNC worked fine with the new value input for resolution.  The remote desktop came up fine with an doubling of the Mate panel.  Mageia updater was calling for attention so I ran it from the remote and watched the commands echo on the real monitor.  It worked fairly smoothly with x11vnc caching.  Unfortunately I did not write down the keystrokes required to get out of fullscreen mode.  Stuck with a black border so shall have to crash out at the server end.  Anyway, this confirms the 64-bit OK.
Comment 19 PC LX 2020-04-10 17:07:46 CEST
Installed and tested without issues.

Tested using x11vnc, krfb and linuxvnc servers along with krdc client. No issues noticed.

System: Mageia 7, x86_64, Plasma DE, LXQt DE, Intel CPU, nVidia GPU using nvidia340 proprietary driver.

$ uname -a
Linux marte 5.5.15-desktop-3.mga7 #1 SMP Sat Apr 4 19:06:09 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ rpm -q lib64vncserver1
$ rpm -q krdc krfb x11vnc linuxvnc
$ urpmq --whatrequires lib64vncserver1 | sort -u

CC: (none) => mageia

Comment 20 Thomas Andrews 2020-04-10 17:12:57 CEST
Thank you for your persistence, Len, and thank you PC LX for responding to my email request. 

Validating. Advisory in Comment 4.

CC: (none) => andrewsfarm

Thomas Andrews 2020-04-10 17:13:59 CEST

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Thomas Backlund 2020-04-15 10:55:12 CEST

CC: (none) => tmb
Keywords: (none) => advisory

Comment 21 Mageia Robot 2020-04-15 12:13:41 CEST
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

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