Critical Flaw Found in VNC 4.1

jblobz writes "IntelliAdmin has discovered a critical flaw that allows an attacker to control any machine running VNC 4.1. The flaw grants access without the attacker obtaining a password. The details of the vulnerability have not been released, but their website has a proof of concept that allows you to test your own VNC installation for the vulnerability"

Comments

SSH

[Anonymous Coward]

You should tunnel unencrypted services like VNC over SSH anyway.

Yikes!

[timeOday]

Surely inspection of the vulnerability test will betray the flaw to attackers?

Re:Yikes!

[julesh]

But isnt the slashdot crowd always for the release of exploits?

Yes, indeed. However this isn't a release of an exploit, it is somebody saying "bring your machine, and I'll exploit it for you."

What this means, effectively, is that anyone who is prepared to go to the effort of sniffing packets can easily figure out what's going on, but the rest of us are still in the dark. I can't use this to test the machines on my internal network because there's no way I'm going to open the VNC ports on my firewall. He may be wrong when he says on the previous article that (e.g.) TightVNC isn't vulnerable, it may be vulnerable to a slight variation of the attack that could easy be found by somebody who knew how it worked, but because he's released no details to anyone who doesn't make a large effort to understand the problem we can't know that. But be sure that there are some blackhats out there who have already tested this and understand why it works who have tried to figure out if they can make it work on another version.

This behaviour is wrong in every way possible. Disclosure should be complete or not exist at all, IMO. Anything between is dangerous.

tight vnc

[bazooka_foo]

i guess tight vnc is okay??

that is what I use

SSH tunnels

[ArbitraryConstant]

Like many services meant for users that can be expected to have a password, this is best tunneled through SSH. Access is controlled by a comparatively secure protocol and server. It's still best to patch (eg someone might get unpriviledged access to a machine and use this flaw to escalate the breach), but having a gateway that's more secure than any of the components behind it is nice. Even if the gateway itself has flaws from time to time.

Capture the packets

[a_greer2005]

The hole hasnt been detailed but they have a web baced proof of concept exploit? do I need to spell it out for you? SNORT the segment while you run the test and BINGO -- Got 'em!

scope of bug...

[AmigaAvenger]

only RealVNC is affected, which is a crappy vnc anyway. TightVnc and better yet UltraVNC are far ahead of RealVNC, neither of which are affected btw.

Re:scope of bug...

[petard]

only RealVNC is affected, which is a crappy vnc anyway. TightVnc and better yet UltraVNC are far ahead of RealVNC, neither of which are affected btw.

I wouldn't assume they aren't affected by this. They very likely aren't, but it looks like this guy stumbled upon the flaw as he was implementing an independent VNC viewer from the VNC specification. It doesn't sound like he really has his mind around why RealVNC is affected, so it'd be prudent to assume that they are. (i.e. Once he understands why the attack works he may be able to produce one easily against TightVNC and UltraVNC.)

At any rate, if you operate your VNC service in a reasonable configuration, you're safe. By "reasonable configuration" I mean listening only on 127.0.0.1 so that people have to connect via ssh or client-authenticated stunnel to get to it. VNC authentication is not safe on an untrusted connection. And you shouldn't trust your connection unless your network is so small and has such well-controlled access that you can physically inspect every device on it in <30 minutes with absolute certainty that you haven't missed any.

Re:scope of bug...

[pe1chl]

Our experience with *VNC has been that "better" is often subjective.
We used the original VNC for quite a while then switched to TightVNC. It seemed "better", but on the Windows platform there were some situations where it had difficulty finding the need to redraw certain screen areas.
(I am of course assuming that the 'poll full screen' option is not used, but limited areas of the screen are polled)
Sometimes a click on a window bar is needed to refresh that window, sometimes it is enough to move the mouse around a little.
The ancient version did allow you to refresh the screen by "painting" the area with the mouse cursor, but TightVNC usually refreshes an entire updated area when it is moved over by the mouse.

However, as there still were apps which did not work entirely satisfactorily (especially when extensive use was made of tooltips), we kept looking and it seemed that UltraVNC was promising. It was installed on a few systems and it worked ok, then rolled out to a lot of systems.
Now, problems again appear, but in other situations.
Sometimes it delays refreshing a bit long, and shortening the timer increases the CPU usage too much.
Using the special video driver improves things a little, but it has proven difficult to find a really well-working setup that does not have annoying lag and does not overload the system either.
One one system it was even replaced by RealVNC because of system load issues.

Fortunately all those servers and clients inter-operate, or else there would be a big mess by now.
(also, we fortunately can automatically and silently install new or other versions on at least the client systems, so switching is not too hard)

I wonder what other people's experiences are. I don't define "better" as "having more toolbar buttons" or "having more added options like file transfer", but I am still looking for a better VNC in terms of good interactive performance without overloading the server system.

Re:scope of bug...

[moonbender]

I wouldn't assume they aren't affected, either, but the guy did test Ultra and Tight, and both weren't affected. So there. It's not in TFA, but one link away.

Bottom Line

[bogie]

"I started to wonder how widespread this flaw was so I downloaded TightVNC, and UltraVNC. They are immune. Both of them reject my connection right away"

"So it looks like a flaw is in the current RealVNC 4.1.1 authentication process. I am not going to give any clues as to what it is until I can figure it out totally, and promptly let the RealVNC team know so they can resolve the issue."

So there you go. This is apparantly not a system-wide VNC issue and is a RealVNC 4.1.1 issue only. Submitter you suck.

Company sells remote control software

[srh2o]

I'm a bit skeptical about the motives here when the comapany is in the business of selling Remote Control software. But, I have to agree with the other posters that talked about tunneling over ssh and only allowing connections from the localhost. I'm not sure why anyone would run VNC live on an untrusted network anyway.

SSH Port forwarding

[Savage-Rabbit]

The parent was saying that the problem was not with the lack of encryption, it was a problem with the authentication. He's not saying that SSH wouldn't solve the problem, simply that the problem would not be solved by SSH's encryption like the original poster implied, but its extra layer of authentication which is not affected by this vulnerability.

Unless I am very much mistaken SSH would be a valid work around for the problem and it has nothing o do with SSH encryption although it makes VNC use safer, it has to do with SSH tunneling. Even if the computer you are connecting to with VNC only has port 22 exposed to the internet you can still connect to the VNC server on one of the usual ports in the 59xx range. Before you can do that, however, you first have to use SSH port forwarding by to create an SSH tunnel and physically log onto the target system with the 'ssh' command using the '-L' option. That basically means that you can only get at the VNC server by creating an SSH tunnel first. This makes any authentication vulnerability of the VNC server a non issue, not that a for this bug ASAP would be a bad thing. You should always force users to use SSH when connecting via VNC and not just rely on VNC's native authentication all on it's own.

OS X Affected?

[wo1verin3]

Can anyone check to see if OS X's implemtation of VNC (desktop sharing) is vulnerable?

Re:OS X Affected?

[Anonymous Coward]

Sure, what's your IP address?

And here's how you do it ....

[tarka69]

Start the vnc-server with the following:

vnc4server -nolisten tcp -localhost

Add the following to your ~/.ssh/config:

Host lucretia
        HostName lucretia.dyndns.org
        Compression yes
        LocalForward 5901 localhost:5901

Then ssh into the machine to create the tunnel. You then connect to the remote VNC session with "xvncviewer localhost:1".

Re:FC 4 vnc-server-4.1.1-10.1 tested and passed

[mhesseltine]

you can't use ssh to connect to your Mom's machine in a different city and help figure out why she has trouble using/interacting with Kmail or some other GUI program. But with vncserver + vncviewer, you CAN.

You may want to look into x11vnc, which will allow you to connect to a running X session and view it using VNC. This is how I access my home machine from work when I want to check on a running GUI task at home. SSH in, run x11vnc -display :0, then connect to the tunneled VNC connection. Works great, and when I'm done, I just take down the x11vnc so it's only up and running when I need it.