Ubuntu – Does the newest version of Ubuntu (18.04) have 8 years old x11vnc?

Ubuntu 18.04 x11vnc users.

Here is a "hack answer" which allows you to get VNC access without being logged in.

I say hack as it involves having 2 x11vnc services running.

The first is to allow login via DISPLAY=:0 and the second is to use VNC to get access to desktop via DISPLAY=:1

To achieve this I used the following 2 daemon scripts:

The first is: x11vnc-login.service just for login greeting

[Unit]
Description=Start x11vnc-login at startup.
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -auth /run/user/120/gdm/Xauthority -forever -loop -noxdamage -repeat -rfbauth /home/<ID>/.vnc/password -rfbport 5922 -shared -display :0
[Install]
WantedBy=multi-user.target

The second is: x11vnc.service for desktop:

[Unit]
Description=Start x11vnc at startup.
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -auth /run/user/1000/gdm/Xauthority -forever -loop -noxdamage -repeat -rfbauth /home/<ID>/.vnc/password -rfbport 5920 -shared -display :0
[Install]
WantedBy=multi-user.target

The installation and enablement of scripts is as per documentation on community help site.

This is a horrible hack but gets me running for the time being until a proper solution is found.

In use I first open up VNC session to port 5922 and do login. Once logged in you end up with a black screen. So you then open up VNC session on port 5920 and voila, there is your desktop. Still easier for me than having to go to where the server machine is running...

Obviously what is needed to have some script which does a preliminary search of running processes to see if a user is logged in and if so then just use the XAUTHORITY/DISPLAY info from the existing user section (as extracted from /proc/PROCID/environ, otherwise connect socket up to greeter screen with greeter XAUTHORITY/DISPLAY and then somehow move socket connection over to another x11vnc session using users desktop XAUTHOURITY/DISPLAY values.

A bit of complex fork/socket/file descriptor programming I suspect.

Other possibility is to figure out whether there is some way to get 18.04 display manager to behave as per prior 16.04 one.

How come that new packages are only created for newer LTS distributions and older ones are left vulnerable? is simply FALSE, and let's show you how you can determine that for yourself:

First, Let's take a look at the Ubuntu CVE Tracker.

Key in your CVE number, and you will see:

• The Ubuntu Security Team has already worked this issue.
• Some Ubuntu releases required new packages, others did not.
• The tracker includes the exact package version with the fix.

Second, lots of folks get confused by the Debian/Ubuntu concept of a snapshot release model. Under this model, the software in a single release (like 19.10 or 20.04) is NOT incremented by new releases...even most security releases.

• Exceptions: There are a few exceptions, like web browsers, that always get the newest versions on older releases.

HOWEVER, "not incremented" doesn't mean "not fixed". Lots of packages get security patches after release without being upgraded to a new version. Let's say that again: Users are encouraged to update to newer packages because most users don't have the skill or patience to patch and recompile a package. Distros like Ubuntu, however, have engineers who do have that skill and patience.

• It's risk management: Newer packages may introduce bugs and haven't been tested with the release, so most packages are patched instead.

Finally, let's build on those two elements and let's take a look at the example of OpenSSL in CVE-2020-1967:

• The Ubuntu Security Team evaluated the vulnerability in six different releases of Ubuntu. The vulnerability was present in one of those releases.
• The upstream release (for users) is version 1.1.1g
• The Security Team patched the vulnerability in 20.04's package 1.1.1f. Since they added a patch instead of merging the new upstream release, they couldn't claim it was 1.1.1f anymore, nor was it 1.1.1g. It was something else, so it's called 1.1.1f-1ubuntu2. Note that the '2' in 'ubuntu2' indicates this is the third patch of that package since it came from upstream.
• That labeling scheme for patches isn't accidental - it's carefully designed so you can see at a glance how many patches came from Debian, and how many from Ubuntu. Also, it's still alphanumerically sortable so apt will always correctly identify the highest version to install.
• Finally, after review and testing, the patched package openssl 1.1.1f-1ubuntu2 was uploaded to 20.04 (Focal) before release. Had the patch occurred after release, it would be in the focal-security repository. This is one reason it's important to keep the -security repo in your sources, and to keep Unattended Upgrades active.