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.
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
Debian-LTS has issued an advisory for this today (March 18):
Patches available from Debian and upstream
Done for both Cauldron and mga7!
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:
Patches available from Debian and upstream =>
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.
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.
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
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.
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.
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.
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
$ rpm -q krdc krfb x11vnc linuxvnc
$ urpmq --whatrequires lib64vncserver1 | sort -u
Thank you for your persistence, Len, and thank you PC LX for responding to my email request.
Validating. Advisory in Comment 4.
An update for this issue has been pushed to the Mageia Updates repository.