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"

SSH

[Anonymous Coward]

You should tunnel unencrypted services like VNC over SSH anyway.

Re:SSH

[merryberry]

Windows remote desktop suffers from very weak authentication. The best solution to this VNC flaw and using remote machines in general is to use a VPN to ensure that authentication is managed with public key cryptography, with all data thereafter being encrypted with symmetric keys. It also means it's so much simpler to run different services without having to create separate SSH tunnels. http://openvpn.net/ [openvpn.net] has a great solution working on all platforms.

Re:SSH

[Blakey Rat]

Would if I could. How do I set that up with a OS X server and a Windows XP client? I'm using OSXVNC on the OS X box and the plain jane VNC Viewer on the Windows XP box. Neither seems to have any options for using SSH.

I mean, giving advice like that is fine, but unless you give us more information on how to set it up, you're basically just saying, "I'm so 1337 I know how to do this, and if you don't know how to do this you're not 1337 enough, newb!"

Also, does anybody know if OSXVNC is vulnerable to this f

Re:SSH

[andrew_0812]

Nothing l337 about it. check out port forwarding with ssh:
http://www.ssh.com/support/documentation/online/ss h/adminguide/32/Port_Forwarding.html [ssh.com]

There is a myriad of guides on how to do this. The setup doesn't come from within your VNC apps, but from ssh.

Set up your ssh server and clients. Use public key cryptography instead of a password. Run your VNC server and make sure it is accessable from the machine that is running your ssh server. It can be the same machine, but it doesn't have to be. Don't fo

Re:SSH

[Blakey Rat]

Your entire explanation is complete and utter gibberish to me. To use FTP securely over SSH, all I have to do is change "ftp" to "sftp" or check the little "secure FTP" checkbox in my GUI client... why the hell haven't the VNC people made it easy like that?

Anyway, your Linux instructions might work on my OS X box, but I don't see anything in there about Windows XP.

Re:SSH

[Shanep]

My Resume on Googlepages

From your online resume: "Serving as primary programmer for a multi-player online role-playing game. Duties include maintaining and expanding a large open-source C++ server program, designing and implementing innovative new gameplay features, resolving player disputes, SQLite database administration, and Linux server administration."

But his explanation on ssh tunneling is gibberish?

A word of warning: the resume you intentionally put up on the net with Google is not the only info abou

Re:SSH

[Blakey Rat]

I'm mostly whining about software developers who HATE to make things plain easy. Securing FTP is easy, there's no reason that doing the exact same for VNC should be hard. Because I don't understand what the grandparent posted, that means I shouldn't have access to security... isn't that what the developers of VNC are saying to me?

Whether you consider it rude or not, as far as I'm concerned, everything he typed was technobabble I don't understand whatsoever, and I'm just letting him know that. Plus, witho

Re:SSH

[sumdumass]

Because I don't understand what the grandparent posted, that means I shouldn't have access to security... isn't that what the developers of VNC are saying to me?

I'm not sure the vnc guys are even woried about runing thru an ssh forward. It doesn't even seem to be on thier radar as far as features go. I personaly just woulnd run VNC from outside the network unless i tunneled into it in the first place. Maybe they asumed everyone was that concious, i dunno.

I'm not a newb when it comes to computers. I do how

Re:SSH

[Blakey Rat]

To repeat my problem for the third time, I'm remote-controlling a Mac using a Windows XP computer. GoToMyPC.com only works on Windows, it's useless for solving my problem. As far as I am aware, VNC is the only option for me.

And all that stuff about SFTP only being secure if it's "configured correctly"... why is that my problem? The makers of Cyberduck (my FTP client) are the ones doing the configuring... that's the entire point of software, to reduce complexity. If I wanted to waste all my time learning

Re:SSH

[sumdumass]

To repeat my problem for the third time, I'm remote-controlling a Mac using a Windows XP computer. GoToMyPC.com only works on Windows, it's useless for solving my problem. As far as I am aware, VNC is the only option for me.

VNC isn't the only option. There is apple remote desktop and a few other. But as i stated before, you need to do a little learning. Instead your stuck complaining about a program because it isn't point and click the way you want it. You next comment demonstrates exactly why you are dis

Re:SSH

[snol]

Set up OSX VNC so that it only accepts connections from localhost (I don't know this specific VNC server, but it should be an option. If not, find a different VNC server.) Figure out which display it's running (probably 0), and add 5900 to that number to get the port it's running on. Enable the ssh server on your OSX box; someone else will have to tell you how to do this with launchd because I don't remember, but I've done it and it's not too hard. There's also a freeware tool called sshhelper which is

Re:SSH

[ncc74656]

Would if I could. How do I set that up with a OS X server and a Windows XP client? I'm using OSXVNC on the OS X box and the plain jane VNC Viewer on the Windows XP box.

Mac OS X comes with OpenSSH and only needs to have sshd enabled. On your Windows box, you can use Cygwin to install OpenSSH. If you only need an SSH client (no server) on the Windows box, PuTTY will work.

Re:SSH

[AmigaAvenger]

maybe you haven't used ssh before, but when you tunnel stuff over ssh you no longer even care if vnc has a password! the ssh tunnel drops you behind the firewall or directly on the console of the machine, all traffic goes over ssh, which means you already have logged in with a valid username/password.

Re:SSH

[Anonymous Coward]

Gah, pay attention.

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.

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.

Re:SSH Port forwarding

[ookabooka]

VNC's authentication is PLAINTEXT. It's just a little authentication thing to keep random people out, and is by no means secure. FTP is the same way, username/password are transmitted plaintext. The article is a short blurb about how they discovered a way to completely bypass authentication, so even random people have access to your desktop. IMO, if you are doing anything where security is atleast of moderate concern, you should close the port and do ssh tunneling. Otherwise you have to be willing to accep

Re:SSH Port forwarding

[ComaVN]

vnc authentication is not plain text, but anything you do over it (like logging in to your account) is.

Re:SSH Port forwarding

[stinerman]

Correct.

It authenticates only the first 8 letters of your password and uses a pretty weak DES challenge algorithm. After that, everything else is in the clear.

Re:SSH Port forwarding

[dnoyeb]

I guess you can call it neat. Hey were not going to tell you how to break into your computer, but you can let us break into your computer for you. We don't trust you, but you should trust us.

I use VNC over ssh all the time. Anything I do is connected over ssh, except samba which is blocked by my two broadband router/firewalls. Matter of fact, vnc is also allowed out of my linux box, but blocked by the firewalls. Makes easier to connect from downstairs to upstairs, but not by much honestly.

Re:SSH Port forwarding

[owlstead]

Most of the time, when I try and connect to a server online, the TCP connection to the service is pretty secure. Unless my ISP/telco, who are quite trustworthy, try to break into the session there is no way anybody is even going to see my VNC connection. On the other hand, unless I take special measures, absolutely anyone can attack the VNC service. SSH has quite a bit of overhead, so just saying I have to use that does not make me too happy.

In other words, this can make for a much bigger target for hackers

Re:SSH Port forwarding

[redcane]

But if your running VNC without authentication, who is it running as? If it is running as and someone ssh'ed in as a guest, they can tunnel to the VNC session. You still want working authentication on VNC unless you *really* trust all the users on your network/box, or have some nasty firewall rules (even with a firewall you can't stop people connecting locally, or you lock legit users out).

Re:SSH Port forwarding

[gk2004]

SSH tunneling helps a lot, but it does not protect you against other users on the VNC server machine.

Re:SSH

[riffer]

You are confusing interactive SSH logins with VNC logins. Your message is, sadly, not informative and in fact misleading.

Tunneling a protocol over SSH does not eliminate the need to authenticate on that protocol! The very nature of tunneling means whatever protocol is carried down the tunnel is unmodified

Tunneling VNC over SSH simply means you establish a secure shell connection and do port forwarding between your target host and your client. Your client forwards connections to the localhost on a speci

Re:SSH

[glesga_kiss]

I'd rather add proper SSL with certificate verifications and all to the applications. It's not even hard actually thanks to the OpenSSL libraries. It's also more secure and cleaner.

It's not more secure at all. By allowing new services to listen on publicly accessible ports it is impossible to be more secure. You can only increase security by taking away services. By definition, adding more is adding vunerabilites.

If SSH is your first line and you use tunnels to get at everything else, no one can access

Not enough details

[Raleel]

It says that the VNC port has to be accessible from the internet. Normally, I don't do this. I run it so that you can only connect from localhost and ssh tunnel through. It doesn't detail if it would affect an installation like this, but I doubt it.

Re:Not enough details

[GooberToo]

You missed the point. He's saying no one can reach his box unless they have SSH'd into hix box first. That means he's not likely at risk unless someone has gotton past SSH first and/or already have a local account.

Re:Not enough details

[micheas]

Your system is affected just as much as any other. Unless the machine is single-user, all other users on the system will be able to exploit VNC.

This is wrong. A system that only accepts connections via the loopback interface is only subject to privilege escalation attacks. This is a far cry from a remote compromise. In a system with untrusted users this is still a big deal but it is far less problematic than remote compromise.

System administrators should understand that binding a service to loopback is not

Yikes!

[timeOday]

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

Re:Yikes!

[alexmipego]

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.

Re:

[account_deleted]

Comment removed based on user account deletion

Re:Yikes!

[Cyberax]

Don't worry, we've slashdotted their server already :)

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.

Re:Yikes!

[csoto]

But he 1337 h4x0r! He pwn3s!

Totally agree with you. Disclosure is a necessary FORMAL process. It involves complete academic review. Those that do it can right can find gainful employment as security professionals.

Re:Yikes!

[dorkygeek]

And the others? PROFIT??

tight vnc

[bazooka_foo]

i guess tight vnc is okay??

that is what I use

Re:tight vnc (NOTE TO MODERATORS)

[julesh]

Erm... "yes, it is."

Note to self: proofread post before posting.

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.

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:And here's how you do it ....

[David_W]

Unfortunately, your instructions don't help with Win2k Pro and Cisco CallManager installations.

They would if you were running OpenSSH from Cygwin [cygwin.com], wouldn't they?

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...

[ImaLamer]

Except for encryption, but this makes encryption worthless.

It's all the same.

Thank you.

[CFD339]

This bit of information was useful to know, and didn't make the /. summary.

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...

[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.

Re:scope of bug...

[petard]

I read that link, and that's actually the one that made me think they might be vulnerable. It's clear that they aren't affected by this particular stream of bytes that compromises RealVNC. i.e. They're not impacted by the proof of concept. That says nothing about whether they're vulnerable to he same attack. Dig around on the site a little, though for details of the vulnerability and you'll see that the finder doesn't currently understand it.

Given that the flaw finder does not understand why his stream of b

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...

[rduke15]

I also have the problem with TightVNC that the screen may not be refreshed correctly before some dexterous mousing is performed.

So I'm also interested to hear about alternatives...

Re:scope of bug...

[RebornData]

UltraVNC is part of my standard install set, and I've never seen substantial CPU utilization on machines that have the display driver correctly installed. Have you verified that it's loaded and actually working? You can tell by right-clicking the VNC helper icon in the system tray and choosing "Properties" (not Admin properties).

-R

Re:scope of bug...

[pe1chl]

Yes, it is installed.
My experience is that the "poll full screen (ultrafast)" mode can use a lot of cpu in certain cases. Not always. I have not really identified the exact problem.
So we usually do not enable this. Then it works satisfactorily in other versions, but in UltraVNC there often is a quite long lang before updates are shown when there is no user action.

I need to spend some time to really debug this, because "it is slow" comments from users are often difficult to interpret. Sometimes it is slo

Re:scope of bug...

[pe1chl]

*VNC works on the login screen when you install it as a service.

During workstation installs, we install it as a service but then later set that service to "Manual". You can then remotely start the service after the system has booted (via Manage and Connect remote computer) and take over the login screen.

TightVNC has a bug here: it disconnects when you login. But it remains active so you can connect again and see the logged-in desktop.
Other versions remain connected through the login processing.

Re:scope of bug...

[leuk_he]

only RealVNC is affected, which is a crappy vnc anyway.

I switched from utralvnc viewer to realvnc viewer because it was much faster on a low end machine. So it might be crap for you, it works for me.

Re:scope of bug...

[Alexey Nogin]

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.

Well, RealVNC comes with a XFree/XOrg driver (vnc.so) that gives a very natural way to share the "native" X session. This is extremely useful when you want to have the normal X session on your machine (running at a normal speed), but still want to preserve the ability to connect to it remotely via VNC. AFAIK TightVNC does not allow anything like that and Ultr

encrypted wireless?

[Zugok]

I run VNC between two computers over a MAC filtered (yeah yeah I know...) and encrypted wireless connection, should I be (less) worried at all?

Re:encrypted wireless?

[Anonymous Coward]

If WEP, then you should be very worried. If WPA then less worried (assuming your key is actually at all good). Also this only affects RealVNC (I believe). Also MAC filtering is pretty much only 'useful' to prevent people from accidentally connecting to your network (same with WEP).

Re:encrypted wireless?

[pe1chl]

When I have a point-to-point link, where both sides have MAC filtering to allow only the other side's MAC, and both sides are always powered on, will MAC filtering prevent others to connect?
I mean, will the duplicate MAC mean that just everyting refuses to work (limiting the damage to a DOS) or is it possible to connect two stations with the same MAC and still have useful two-way communication?

Re:encrypted wireless?

[pe1chl]

I believe in multiple layers of security. Of course there is WPA encryption (using the AES algorithm and a long key generated by /dev/random), but I like the idea of having those two boxes just linking to another and to nothing else. When MAC filtering offers that additional security that is nice. I am not turning off all security options but one, just because that one option is supposed to cover everything and thus all other options are not required.

In fact, it is security-wise much more important that

Re:encrypted wireless?

[pe1chl]

I think this contradicts what you said earlier.

My original question was: would MAC address filtering on a point-to-point link that is ON all the time prevent anyone to connect because the duplicate MAC would cause trouble. You said yes, I think so.

I see this as similar to having two boxes with the same address on a wired LAN. Sure someone can change his MAC and IP address and be an imposter on a (supposedly non-switched) LAN, but he will not be accomplishing too much as all TCP connects he is trying to ma

Point taken, and very true, but please...

[Ayanami Rei]

...do us a favor. Don't ever link Gibson Research on Slashdot ever again. Steve is such an attention-grabbing tool.
And you want us to sit around and listen to a fucking podcast? Jesus christ, do you think we have nothing better to do? A quick HowTo or Wiki is just fine, thank you.

But yeah, MAC address filtering has no purpose other than to frustrate you when you use a new network adapter.

Re:encrypted wireless?

[pe1chl]

You are obviously a beginner. Calling other people stupid because they express concerns about basic security issues, and then referring to GRC to make some point, really shows it.
I congratulate you with your belief in WPA and AES. But I expect that you considered WEP the same way before it turned out to be not so secure.
And you completely disregard the fact that even a strong protocol can be weakened by its implementation. The firmware in the access point might have a bug that enables outsiders to circum

Re:encrypted wireless?

[glesga_kiss]

If WEP, then you should be very worried.

Not neccessarilly. WEP isn't all that bad if you update your firmware and change keys periodically. The updated firmwares avoid the weak keys that lead to the vunerability.

MAC filtering is pointless with encyption. Faking a MAC is childs play, all you'd need to do is break the encryption and sniff for a MAC address that was allowed. MAC filtering is only useful when you don't want encryption at all but still want some kind of rudamentary access control. Easilly br

Specific to RealVNC 4.1. TightVNC and UltarVNC OK

[McGruff]

From the initial article preceding the proof of concept, TightVNC, UltarVNC and RealVNC 4.0 are not affected.

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.

Re:Bottom Line

[Zugok]

Well I guess that answers my specific question [slashdot.org] as I use UltraVNC. Still it might be useful to know the answer. Whenever see VNC, I think the whole system, not individual clients so yeah story summary was a little misleading.

OMFG!!

[LoztInSpace]

OMFG! There's software that allows someone to take complete control over my machine?!?!?! Gah!! What sort of bastard would write such a hideous virus/worm thingie!??!

(yeah - I know..it's a joke)

Re:OMFG!!

[Spy der Mann]

Well, there's already an invention which takes control of your MIND.

It's called T.V.

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

[layer3switch]

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.

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

[markdavis]

> For this test, I have activated vnc server
> (why need vnc when you have ssh.. who knows..*sigh*)

Um, because you can't use ssh to connect to an existing/running collection of Xserver and Xclients. Sigh.

Inotherwords, 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.

It is annoying, because what would be 1,000 times better for *ix->*ix would b

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 [karlrunge.com], 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.

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

[markdavis]

>You may want to look into x11vnc, which will allow
>you to connect to a running X session and view it using VNC

Yep- I already use X11vnc, even at work. It is extremely useful. But VNC can't touch the native X protocol in speed or accuracy.

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

[markdavis]

> "*ix" (and "*nix") doesn't match "linux", so stop using it you stupid moron.

I can see why you posted anonymously.

What do you suggest people use, oh polite and insightful one? "*ix" is a hell of a lot easier to type than "Unix, Linux, BSD, and other Unix-like/clone operating systems" and generally, everyone knows exactly what you mean.

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

[layer3switch]

I rather use ssh XForward than VNC if I ever remotely (well, I never) need GUI. Call me simpleton, but that's just me.

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

[armitage_23]

Using VNC over an SSH can be much faster than XForwarding. For instance, when you have a high latency link or the application has 32-bit icons.

Using a VNC desktop and squashing the color depth down gives a huge speed up.

It can also help when you're moving from meeting to meeting. I leave a VNC session running with a few apps, and I can connect to it from various physical locations, even if my IP changes or I have to turn off my laptop. Try that with X forwarding.

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

[Nazo-San]

Don't forget. VNC is OS independant. I can fire up a VNC session on my linux box and use a VNC client on the box itself then leave the session open and connect to it from a windows box. Ok, via Cygwin you can pull off X, but, it is definitely not worth all that extra clutter when a simple VNC client can achieve the same purpose and is designed to do it better (remote X is really intended for a lan dumb client type setup whereas VNC can be used to add JPEG compression, decrease color depth, etc so works a

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

[GiMP]

> Don't forget. VNC is OS independant. I can fire up a VNC session on my
> linux box and use a VNC client on the box itself then leave the session
> open and connect to it from a windows box. Ok, via Cygwin you can pull off
> X, but, it is definitely not worth all that extra clutter when a simple VNC
> client can achieve the same purpose and is designed to do it better (remote
> X is really intended for a lan dumb client type setup whereas VNC can be
> used to add JPEG compression, decrease c

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

[glesga_kiss]

XForwarding is only good on a reliable local network. If you are using it to a remote site and the link goes down EVERY SINGLE ONE of your apps (even the desktop) crashes and terminates uncleanly. This makes running long jobs a bit of a no-no.

And as the other poster said, VNC can be faster in many situations.

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

[MrCreosote]

Also, you can connect to a remote server from your office, kick off a long running job, disconnect, go home, and then reconnect when you get home to see how it is going.

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

[layer3switch]

Post your IP address and we can test properly it for you ;)

"we"? oh boy... Gollum, is that you?

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.

Re:Company sells remote control software

[stinerman]

I'm a bit skeptical about the motives here when the comapany is in the business of selling Remote Control software.

I would be as well, but the software is under the GPL, so I don't think they're going to be trying to throw any backdoors in there without some serious obfuscation.

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?

Re:OS X Affected?

[Lactoso]

127.0.0.1

Re:OS X Affected?

[Dragonfly]

OS X doesn't use VNC for desktop sharing, it uses Apple Remote Desktop, which is a proprietary protocol and shares no code with VNC.

I'm assuming that since this bug is specific to RealVNC 4.1.1, OS X VNC servers like OSXVnc aren't either.

VNC is an important tool

[grumpyman]

I don't know about you guys but VNC is very important to me, and I dare to say almost all of my technical co-workers' daily work. Buggy or not, kudos to the developers.

Re:VNC is an important tool

[birder]

I've never seen the need for VNC. If you're connecting to a Windows box, use rdesktop/remote desktop. If you're connecting to a Linux/Unix machine, use ssh and tunnel X over it if you need pictures (Install Cygwin on Windows machines for X - a much better tool to install than vnc). In fact tunnel 3389 over ssh as well so as to not expose the machine outside the private network.

Heres a reason

[tacokill]

For those with XP Home edition, there is no remote desktop. VNC is a reasonable and free solution.

I like VNC BECAUSE it's simple, effective, and ridiculously easy to setup. Makes troubleshooting remotely very easy. But I run it over tunnels, not in the open. Additionally, you can use a java client to connect so it makes the native OS less important.

Re:Heres a reason

[birder]

Fair enough. My experience is in server farms consisting of Win 2k/2k3 machines and my own XP pro box at home. I really don't like the idea of 1) having a 3rd party app running (which is shown to be insecure) and 2) leaving machines logged in for VNC access - at least that's how people use it here until I catch them and logged them off/remove vnc.

If you're on a non-Windows machine, I find rdesktop incredibly fast to connect to a Windows machine. Far better than vnc or even remote desktop from windows->w

Re:VNC is an important tool

[grumpyman]

Tunnelling X for all linux platform is useful but only unix. I have not use rdesktop/remote desktop.

There are couple of reasons we use VNC. One is we're dealing with a lot of OSes. I'm not sure if one can remote control a W2K box from a Solaris box. VNC is something widely available on all platforms. Second, which gives a reason more preferable to tunnel X is that, one can pop open all the required terminals/applications running on a VNC session, and when working with others, just ask them to pop ano

Built-in VNC server in Mac OS X vunerable?

[Kadin2048]

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.

Re:Built-in VNC server in Mac OS X vunerable?

[Anonymous Coward]

The Remote Desktop server process that runs in Mac OS X does provide support for legacy viewers (it uses an enriched protocol when talking to actual ARD clients), but it does not contain code from other VNC servers (trust me ;) )

This vulnerability is with the Windows-based RealVNC server and its protocol implementation only, and not with the protocol itself.

RealVNC

[penguin-collective]

This appears to affect RealVNC. That's a big problem for RealVNC; even if a similar bug existed in other VNC implementations, it wouldn't matter there.

Why? For other VNC implementations, people have to use ssh tunneling (no built-in encryption), but RealVNC is supposed to offer secure end-to-end encryption without ssh tunneling. If that doesn't work or if the RealVNC developers can't be trusted not to screw up, the whole raison d'etre for RealVNC goes away. And, in fact, RealVNC is built into devices (e.

Ouch! However...

[Idaho]

...it is a good idea not to run VNC all the time anyway. It'd be dangerous even if it was completely designed from the beginning with security in mind, which it wasn't. I'm not even sure that the password is sent encrypted (probably it is by now), but certainly the normal traffic is not encrypted AFAIK.

Also, there have been vulnerabilities before.

This, of course, is not good, but whether it is acceptable also depends on the purpose that you're using it for.

I installed VNC on the computers at my parents place, but it's disabled by default (but put in an obvious place in the start menu). When there is a problem, my parents can call me, I'll tell them to start the "Remote control thingy" (1 click in the start menu) and then I can reach the computer.

Not much can go wrong that way, of course someone could intercept the traffic etc. if they like to stare at default windows desktops I wish them good luck.

However, don't type the admin password over VNC, I'd guess...it's like doing 'su root' over telnet....

Re:Ouch! However...

[ledow]

And like any such plaintext algorithm, suitable wrappers exist and should ALWAYS be used.

UltraVNC incorporates custom extensions that implement a Microsoft encryption DLL on Windows machines (also works flawlessly through Wine). Coupled with UltraVNC SC, you can create a single executable that anyone can download from your website and run and it will connect, fully encrypted, back through whatever firewall they have to your machine which (if it is running a suitable client) will take it over as normal.

Or y

Alarmist

[porkface]

VNC has always had exploits. It was never designed to be secure. It was built for cross-platform system management on LANs, and everyplace I've ever downloaded it (except the RealVNC site) has always carried the original AT&T labs disclaimer that it is not a secure service.

RealVNC has always tried to market up their version, and has been the fastest to add new features; two common warning signs when looking at a software's level of security.

one workaround

[sl4shd0rk]

Is to post your vnc server on slashdot, thereby disabling any vnc access for you http://www.intelliadmin.com/blog/2006/05/vnc-flaw- proof-of-concept.html [intelliadmin.com]

RealVNC 4.1.2 released

[staplin]

RealVNC has already released a 4.1.2 update [realvnc.com] that closes the vulnerability.

Nice :)

[jgoemat]

A guy who works for a company that produces remote administration software finds a bug in VNC that he says will allow anyone to take control of any computer running VNC, then has it posted to slashdot, then takes down the test page because slashdot was too much for his server. Profit motive anyone?

Edit the title

[jgoemat]

Please change it to read "Flaw found in RealVNC 4.1.1", other VNC products don't appear to be affected, including RealVNC 4.0.

Re:RealVNC

[grub]

Answering my own question, from this link [intelliadmin.com]:

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.