A security issue discovered in libvncserver has been mentioned here: https://www.openwall.com/lists/oss-security/2019/12/20/2 There doesn't appear to be a fix available yet. Mageia 7 is also affected.
Whiteboard: (none) => MGA7TOO
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
Debian-LTS has issued an advisory for this today (March 18): https://www.debian.org/lts/security/2020/dla-2146
Status comment: (none) => Patches available from Debian and upstream
Done for both Cauldron and mga7!
Advisory: ======================== 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). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15690 https://www.debian.org/lts/security/2020/dla-2146 ======================== Updated packages in core/updates_testing: ======================== libvncserver1-0.9.12-2.2.mga7 libvncserver-devel-0.9.12-2.2.mga7 from libvncserver-0.9.12-2.2.mga7.src.rpm
CC: (none) => geiger.david68210Version: Cauldron => 7Status comment: Patches available from Debian and upstream => (none)Whiteboard: MGA7TOO => (none)Assignee: geiger.david68210 => qa-bugs
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
mga7, x86_64 No better here Herman. Running $ 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
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.
What if you don't use the DesktopSize argument? Is it a regression?
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 PORT=5900 [...] 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.
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.
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?
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
What about linuxvnc or remmina?
Have installed linuxvnc. Shall try it out later - need sleep.
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.
remmina-plugins-vnc uses libvncserver.
Yeah, thanks David. I had just discovered that: "Correction regarding remmina. remmina-plugins-vnc does need the library. Installing remmina-plugins-vnc."
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.
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 lib64vncserver1-0.9.12-2.2.mga7 $ rpm -q krdc krfb x11vnc linuxvnc krdc-19.04.0-1.mga7 krfb-19.04.0-1.mga7 x11vnc-0.9.16-1.mga7 linuxvnc-0.9.10-4.mga7 $ urpmq --whatrequires lib64vncserver1 | sort -u krdc krfb lib64vncserver1 lib64vncserver-devel linuxvnc remmina-plugins-vnc x11vnc
CC: (none) => mageia
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
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
CC: (none) => tmbKeywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0164.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED