Slashdot Mirror
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"
i guess tight vnc is okay??
that is what I use
I have FC 4 2.6.16-1.2108_FC4smp kernel with some minor kernel sweak. For this test, I have activated vnc server (why need vnc when you have ssh.. who knows..*sigh*) with default config and disabled my paranoia iptable rules for this test. Also opened up port range from 5800 to 6001 (just to prove the point) from my firewall and set to port forward to VNC machine.
I even disabled password for the account VNC display is binded to and set to no encryption for VNC.
Nothing happened. No display, nah da, nothing.
I have stable FC4 vnc package version 4.1.1-10.1.
"Don't let fools fool you. They are the clever ones."
I was thinking the exact same thing. Since they allow you to test that, an hacker can setup a machine with a vunerable version and use a sniffer to see what the proof of concept code is doing.
This guys will be responsible for a few server's hacking.
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.
.sig: file not found
Does anyone know if this exploit affects the VNC server that is built in to Mac OS X? I've never been clear on which mainstream software package it's based on (if any, it doesn't make it obvious either, it's just "VNC Access" and a checkbox, but I can't imagine Apple would have rewritten a VNC server from scratch if they didn't have to).
There's no real good way to set up that service with an SSH tunnel -- I think it's intended use is only on local networks when you're behind a firewall, but on the other hand there's nothing that marks it as being screamingly insecure when you go to turn it on, either (IIRC). If you want to tunnel it, or rather, if you want to limit access to connections that are coming in via an SSH tunnel, I think you have to run a regular VNC server and set it up manually.
The test page is down right now so I can't check it one way or the other, but I'd be interested to see if anyone knows what code is actually used for Apple's built-in VNC server, and whether people believe it's vunerable.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
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.