RDP loves company: Kaspersky finds 37 security holes in VNC remote desktop software VNC remote desktop software has no shortage of potentially serious memory-corruption vulnerabilities, you'll no doubt be shocked to hear. This is all according to [PDF] a team at Kaspersky Lab, which has uncovered and reported more than three dozen CVE-listed security holes, some allowing for remote code execution. VNC, or …
It's implied that TightVNC 1.x has continued in use although unsupported. This must be partly because you have to pay (pay again ?) forTightVNC 2.x, which declares as not containing GPL program code and seems to be not covered by this testing. The question then... were users told that TightVNC 1 would be unsupported from date x, and were they told that before date x? Well... it's entirely credible, of course, that many users went on running the old product after they knew in good time that the guarantee of maintenance, such as it was, was withdrawn. However, when it was supported, evidently bugs were in it dating from 1999, the whole time.
From the TightVNC download page:
[quote]Licensing Terms
There are two licensing options available for TightVNC software:
GNU General Public License version 2 (often abbreviated as GNU GPL). This is the default licensing option. It's completely free but it does not allow integration with closed-source products. Read the complete text of the license here (opens in a new window).
Commercial source code license. Unlike GPL, it allows integrating the software into proprietary products, although it's not free.[/quote]
So it seems you can use the latest 2.X version under GPL, only integrating with closed source software requires the commercial licence.
From: https://www.tightvnc.com/download.php
"Older Versions: If you need a version working in Windows 95/98/ME, Windows NT 4.0, or in Unix-like systems (including Linux), download TightVNC 1.3.10. "
So it looks like if you are using it on linux, you will have to change to something else/
So it looks like if you are using it on linux, you will have to change to something else
oh, so THAT is what happened! [I don't use Win-10-nic and haven't VNC'd with a windows box in FOREVER... so that is probably why I had to switch to Tiger VNC for BSD and Linux - lack of current X11 support etc.]
windows-only. THAT is @#$%^ *DISAPPOINTING*.
I've been using Tiger Vnc which is a fork of TighVNC... because for quite a while it seemed out of date and wouldn't handle certain GLX things that Mate and other systems needed support for. So I switched.
from the article:
600,000 public-facing machines offer VNC access
These people exposing "known port" VNC connections MUST understand it's a security risk already... what, does VNC protocol's pathetic password protection actually HELP? do ya think? yeah, should be obvious, right? I wonder how many OTHER firewall logs have shown a zillion daily attempts at banging on ports 5900-5999 looking for VNC...
(they should be using a VPN and ONLY listen on private addresses at the very least and NOT exposing those ports to 'teh intarwebs')
But then again, WINDOWS machines are INFAMOUS for "listen on *.*.*.*" so there you have it. Unless you explicitly put a firewall between 'teh intarwebs' and your windows boxen, you're insecure (apparently) by DESIGN.
Sure, putting ANY windows on a public IP is just STUPID these days. So, at least firewall it with a LINUX box, at the VERY least! [you could even use an RPi to do it if you add a 2nd network adaptor or make it a WiFi access point]
And when you need VNC access from 'teh intarwebs' you should use a VPN or ssh anyway. It's just common sense.
VNC into a KVM seems to work ok for me and I've used it a LOT actually... but usually by setting up an ssh tunnel so I'm listening on a specific IP address [usually localhost] on whatever machine I want to access it from. To make that work you can have a headless (Linux or BSD) VM that makes an ssh connection onto another machine (let's say a server) and directs incoming "server:xxxx" to "vm:22" for ssh. Then, just do something like "ssh server xxxx" to access it. That's how I've been doing it, anyway.
THEN, for VNC access, you use something _like_ TigerVNC server to actually run the desktop, and set up VNC tunneling via the ssh connection [same basic idea] and VOILA! you open VNC and you now have the full desktop. (you can also do this on an RPi that's headless to access its desktop via VNC).
This works exceptionally well when you want to have KDE on your Mate machine, or if you want to do X11 debugging from a GUI [so you run the debugged program in a VNC session, which is a different X server and isnt going to lock up on you if you break in the middle of certain libX11 calls...].
Anyway, ssh + sshd tunneling magic works fine. A bit tricky at first, but there are many examples in duck-duck-go-land
I'd still do the tunnel. It's been my experience that things _like_ VNC aren't trustworthy enough on their own, and it would just be simpler if you always use them via SSH and NEVER expose their ports to 'teh intarwebs'. It's kinda like "safe surfing". No amount of anti-virus or similar things will stop the daily pounding on the expose ports, nor prevent a 0-day exploit. Use SSH and firewall it.
If RealVNC prevents reverse engineering, then what happens if the vulnerabilities found in the others are tested against RealVNC as a black-box test. This will give a view as to if its better by not having those vulnerabilities or just hiding behind a pretend wall. I know where my money is on this one.
Even if not all the vulnerabilities detected in the others can be tested from the outside, a sample of n that give correlation to the others will help in giving a view of the likely risk
Alternately, and the far easier option. Dump RealVNC and go for something else given that the security can't be independently verified and remote console access is kind'a important from a security perspective.
RealVNC: Has TLS encryption built-in for MANY years including certificate handling and automatic certificate generation upon installation. And I am used to its good usability.
UltraVNC: Whoa, still hackish encryption plugin hell! No improvement since Windows 98... https://www.uvnc.com/downloads/encryption-plugins.html
TightVNC: What is encrpytion? Oh, planned for future, maybe https://www.tightvnc.com/faq.php#howsecure
TigerVNC: A Spinoff of TightVNC with TLS, actually looking good! But requires external certificate tools (avail in every OS) for more than "Anonymous TLS", which requires more work, but still looking good for a free program - sadly not tested by them?
TurboVNC: Huh? For Windows ONLY the viewer? Though they have encryption, but I couldn't check for obvious reasons ;).
This post has been deleted by its author
TigerVNC: A Spinoff of TightVNC with TLS, actually looking good!
and generally, TigerVNC has better support for X11, such as GLX support, something that Mate (and apparently gtk3 in general) needs. It's why I switched to it a couple o' years ago, yeah.
I haven't tried the TLS though. And yeah self-signed certs with openssl are built-in except Windows, but I'd just use Cygwin or a Linux or BSD box to generate them for W, so there ya go.
But even with TLS I'd rather firewall it. Mentioned already, the daily poundings on VNC's listening port range by automated crack-bots makes it NOT worth having attached to teh intarwebs'. SSH login attempts are bad enough [but fail2ban helps with that, yeah]
While VNC and RDP offer encryption, VNC offers no real AAA solution and RDP typically will be to an environment where it doesn't utilise a centralised AAA system if one is in-place (i.e. local accounts on one hosts versus AD).
Instead, use one of the many free or commercial VPN options as your transport layer with RDP/VNC over that.
My personal preference is to also use the VPN option for SSH - while SSH can be correctly configured (i.e. no root access, use sudo, use SSH keys instead of passwords), the flexibility of most VPN solutions and the ability of some server "owners" to do silly things in-spite of best endeavours and configuration management systems means standardising for all admin access to hosts via VPN saves a lot of pain in the long term.
There used to be a version of a C compiler which would flag any use of a old-style C string function as a flaw / risk, even something like:
char block[20];
strcpy( block, "foo" ); /* safe because "foo" can always fit in 20 bytes */
Obviously "foo" can never be larger than the target buffer, so it's not possible to be a source of problems.
I wonder how much of their analysis simply counts these sorts of function calls in the code, without actually investigating whether it's a genuine problematic use or not.
The trouble is that the char declaration is likely to be made in a header file or at least not right next to the assignment of its value so whilst the initial code is 'safe' because it fits, it isn't future proof because another developer may be tasked with changing 'foo' to a much longer string, or perhaps to accept it from a config file or user input. That is the the point at which someone inadvertently introduces a serious security bug.
By adopting a coding standard of only permitting safe functions to be used in your code goes a long way to mitigate against this.
So I do see your point that this kind of thing could be called out as a security problem when it's currently not exploitable, but actually one could argue that bad coding practice is bad security practice and should be nipped in the bud.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
