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.

Re:SSH

[Anonymous Coward]

This is apparently a flaw in the authentication method itself, which may or may not have anything to do with whether the protocol happens to be encrypted.

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.

Re:SSH

[Anonymous Coward]

Not really. SSH is actually quite poor VPN solution. It doesn't couple the created tunnel with the application's session. Sure, it "works and is secure", but it's a dirty hack. 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.

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 your resources without breaking the SSH security. You could say that the "all your eggs in one basket" approach is normally wrong, but in security it's the opposite. You only need one hole to get in. Make only one way in and make sure it's as secure as you can get it.

Your idea of using SSL wrapped connections, in this case with VNC, is precisely the thing that this vunerablity would exploit. The exploit is an issue in the authentication. I'm going to stick with SSH's well known, tested and peer reviewed authentication methods for now.

By the way, my VNC password is usually "password". If you are connecting behind my firewall, my security is already broken.

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/ 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 flaw? I wasn't able to test it because the testing site is Slashdotted.

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

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 forward your VNC server port over the internet at the firewall. Just forward your ssh server port.

Now from your client, simply activate the port forwarding. You will be forwarding ports on the local (client) machine that are accessable by your VNC client. I start with 5902:

ssh sshserverurl -L 5902:vncserver:5900

note that vncserver only needs to be resolved by the ssh server, it could easily be an internal ipaddress, or even localhost if your ssh server and vnc server are on the same machine.

Once the connection is established, open your VNC client and connect like this:

localhost:2

That tells it to connect to a vncserver running on the client machine at port 5902 (VNC ports start at 5900 as default and go up from there, the :# identifies the port)

The local port 5902 is encrypted and forwarded by ssh over the secure tunnel to your ssh server, and there it is unencrypted and forwarded to your vnc server.

It takes a bit to figure it all out for the first time, but after that it is pretty simple. You can forward multiple ports to multiple remote machines, even forward ports from remote machines TO your client machine. You can use dynamic forwarding to utlize a remote socks proxy for your browser to sidestep your local firewall. The possibilites are endless. Now you can only open one well secured port to the public, and still access all of your services.

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

[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 a gui that's supposed to walk you through the setup.

On the windows box, get an ssh client (I recommend PuTTY). Set up your connection so that it will tunnel (or forward) from some port, I'll use 5903, on your local machine to port 5900 (or whatever) on the remote machine. PuTTY's docs tell you how to do this; search for "port forwarding." Start your SSH session and log in. You don't have to do anything more with SSH, but just make sure you logged in successfully. Then tell your VNC client to connect to localhost::5903, replacing the port number with the one you actually used, or if it's a number greater than and close to 5900, you can use localhost:3 (in this example) instead.

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

[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 specified port (say, 5900) through the SSH connection to the remote host. So the traffic is encrypted the entire way, but unencrypted once it hits the remote host.

So here's a simple outline of the steps to do:

• Let's say you are using a host named "Guido" and you want to securely VNC into a host named "Barbarella"
• Establish an SSH connection to Barbarella from Guido, enabling port forwarding.
  Let's say you decide to forward connections to 3145 on localhost (Guido, in this case since he's the system you are connecting from) to port 5900 on Barbarella (our target).
• Bring up your favorite VNC client software on Guido and connect it to "127.0.0.1:3145"
• The local SSH client is listening on port 3145 on the localhost (Guido) and detects the connection attempt.
• Local SSH client on Guido forwards all the data it's getting from the 127.0.0.1:3145 connection down the encrypted connection on port 22 to the SSH server on Barbarella. This data is identified differently than standard SSH traffic (i.e. interactive keyboard traffic)
• SSH server on Barbarella takes the forwarded traffic from Guido and sends it to port 5900 on 127.0.0.1 (in this case, Barbarella)
• The VNC server on Barbarella detects an incoming connection and responds accordingly
• The SSH server on Barbarella takes the response(s) from the VNC server and forwards them back down the encrypted pipe to the client (Guido)
• The SSH client on Guido takes the forwarded VNC traffic from Barbarella and sends it to the local VNC client
• Lather, rinse, repeat.
• Profit!

This same procedure is used for any kind of protocol you want to forward over SSH. Note that this is NOT the same thing as the secure versions of some protocols that have been released (i.e. IMAPS, POPS and so-on). Those are modified versions of established protocols where encryption is written both into the protocol standard and the actual software. Most VNC servers do not have built-in encryption.

Note also that some VNC server solutions (such as UltraVNC) do support encryption from the client to server. UltraVNC does it with a plugin architecture, though it's not exactly perfect.

Other important things to note, and to clear-up the rampant confusion in this thread:

• VNC authentication is not plain text. However, the encryption used is fairly weak. It can be decrypted with little effort if the authentication between a VNC server and client is sniffed. Thus, tunneling the VNC connection over SSH defeats that method. However, the password is stored locally on the server in equally weak form. If a person gets ahold of the encrypted form of the server password, they can decrypt it instantly using one of several different vnc password cracking tools (and no, it's not brute force)
• I would not blindly trust the IntelliAdmin website's "proof of conecpt" webpage. They are not publishing this supposed exploit, nor the source to their testing page. So there's no way of knowing what they are doing. Additionally, you are assuming that they (or someone in their organization) will not abuse this access.
• UltraVNC has support for doing Microsoft NTLM authentication, which despite what some may think is more secure than the default VNC authentication scheme.
• Security is about layers. SSH tunnels are great. But you should still use a password on your VNC server and no, you should not tell everyone on Slashdot your password is "password". Even better, keep the VNC server turned off when you are not going to need it (hint: cron can be useful to down the server during the hours you are usually at home sleeping)

Oh, and my CISSP number is 81554.

Re:SSH

[lebean]

"Your entire explanation is complete and utter gibberish to me." The fact that you are clueless about ssh tunneling (it's not point-and-click, but it's *very* close to that easy if you have some basic knowledge) isn't a reason to tell the responder that his reply is gibberish. That comes across as rather rude. If you'd take an hour or two to read some documentation, you'd be setting up your own ssh tunnels without assistance.

Re:SSH

[Captain Splendid]

Jesus, talk about an ungrateful snot-nosed bastard. If you don't like his instructions, go look 'em up online instead of whining like a 5 year old with a skinned knee.

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, without Windows instructions, it doesn't even answer my question. (There was another reply to my original question that was more helpful with less technobabble in it.)

Re:SSH

[dorkygeek]

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!"

Well, so, because I had an ok day today, I'll let you in in one of the best kept secrets of 1337n3ss: 1337 people use a little-known tool called Google. Actually, I am quite worried now that I've told you.

Re:SSH

[Tharkban]

In my client I change

vncviewer the.host.org:0
to
vncviewer -via the.host.org localhost:0

well, I add compression onto the forwarding implied throught the via flag by adding

export VNC_VIA_CMD='/usr/bin/ssh -f -o Compression=yes -L "%L":"%H":"%R" "%G" sleep 20'

to my bashrc.
It doesn't get much easier than that, well unless you're allergic to the command line.

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 however expect to spend some time getting to know the abilities of any new app. It apears you just want a point and click solution without spending any extra time learning to do something. This is fine. It also apears that the learning curve is too great at your current experience level. This is fine too but lets be realistic here. I would suggest using something like GOTOMYPC or some other comercial app that does this already. I'm not doging on OSS or even Free software,it is just known that you need to invest more time then it takes to point and click to run a server or any open presence on the internet and have it be secure and reliable. Even in the microsoft world, you can easily point and click the wrong thing and blow a hole directly in all the other safeguards you put in place.

You mentioned that allo you have to do is click a button to go from ftp to sftp. Well this is only true if ssh is installed and only secure if it is configured properly. If you trust the vendor who initialy installed ssh or suplied the default configurations then good deal but, If the setting are found to be outdated and allows some bug to be exploited, you are no safer then without SFTP except the passwords aren't in the open. Comercial companies have big law firms that negate any liability when thier point and click software does this. Other software companies force you to make those decisions or provide a basic setup with the idea your going to customize it acording to your needs. Now i guess the question might be, Would you trusty the default config for ssh over a perdiod of years? Or may be would a server configured several years ago still be completly secure if only updates were installed? My guess is that the settings should be reviewed along with the updates every so often and any un-needed feature disabled. I guess though, it is how comfortable you are with running whatever your running. Microsoft has decided to almost completly lock down thier products because some of thier users don't realy understand what they are pointing and clicking or just don't know any better (or that they should even make changes) .

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 arcane command-line crap, I'd switch to Linux instead of using a Mac.

In any case, it's inexcusable that VNC doesn't have any built-in security for as long as its been around.

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 disapointed and why it apears your to ignorant to set it up corectly.

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 arcane command-line crap, I'd switch to Linux instead of using a Mac.

Why are you using SFTP if you aren't worried about the security? But to get to the point, You don't even have a clue about what your saying. First, In order to haved SFTP working, you need a corectly configured ssh server, an FTP server and then a client to access it. When you show that you are only dealing with the client side, you are totaly ignoring the server side. But in the VNC you are directly dealing with the seerver side. You cannot directly compare the setup or the amount of effort involved with securing something like a server (even though it is just a vnc or ftp server)with securing a client that accesses them. Now as for software reducing the complexity, sure on the client side but you crossed into the server side and most software vendors expect thier customers to be some what competent with normal server side stuff. Even in windows, you need to do more then just point and click to properly secure it and still have it function as anything more then a simple file server.

This is why I suggest you find (google is a good start)a pay service that does most of this for you. Maybe you just need to employ seom IT guy for a brief period of time to get it going. It just seem that you don't have the ability to grasp the concept or your too arrogent to try.

In any case, it's inexcusable that VNC doesn't have any built-in security for as long as its been around. No, it's not. It is inexcusable for you to use a monkey wrench as a hammer. VNC offers software that does a purpose. It does that purpose well. Securing your network that way you want it secured isn't that purpose. Now if you would have taken the time to learn something, Thier faq sheets about running vnc accross the internet explains the risks and pretty much says it is your responsibility. You can even point and click thru the faq pages and the documentation too. Now, it won't hurt you to spend a little time educating yourself about the products your going to use then later bitch and complain because you didn't read any of the docs.

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 about you which Google will happily dredge up about you for an employer. Telling the World that you think ssh tunneling is difficult might go against you one day.

Some things are most powerful without GUI's and "primary programmers" and "Linux admins" ought not be whining about CLI configs.

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

[AirLace]

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.

System administrators should understand that binding a service to loopback is not a valid means of sandboxing insecure software.

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 a valid means of sandboxing insecure software.

True, but it is a valid way of reducing risk. The mantra is defense in depth. If your VNC is only vulnerable to people with local access it is has a greater chance of not being broken into than if it is vulnerable to everyone on the Internet.

If your VNC is bound to the loopback and you are logging to a remote host you have a real chance of finding out who is guilty of privilege escalation. If it is on a public facing interface you have a lot more work trying to identify the guilty party.

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:Yikes!

[Anonymous Coward]

But isnt the slashdot crowd always for the release of exploits? Or is that just when its MS software involved...

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!

[Cyberax]

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

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!

[squiggleslash]

It's pretty simply really, it turns out that all installations of VNC will accept the following password:

' or 'x' = 'x

* That's a joke. If you don't get it, don't worry. People who've had to fix crappy password authenticators in software based upon SQL will know what I'm refering to.

Re:Yikes!

[alexmipego]

Yeah, I know what it means.

Re:Yikes!

[dorkygeek]

And the others? PROFIT??

hmmm

[ezwip]

If this works on 3.3.3 please let me know cuz I need to be sending IT a message. I'd click the self test but I just started this job and I don't think they would like that very much. ;p

Re:hmmm

[Anonymous Coward]

I think it'd be a safe bet that IT people read Slashdot too.

Re:hmmm

[Acid-Duck]

If you wanna play it safe I'll take your job :)

Erik

tight vnc

[bazooka_foo]

i guess tight vnc is okay??

that is what I use

Re:tight vnc

[mtmra70]

The tight holes seem to be the desirable ones now 'n days.....

Re:tight vnc

[Anonymous Coward]

yeah since our cocks are smaller than the ones our ancestors had in the olden timey days.

Slashdoted

[Amouth]

4 posts and the web server is toast - doesn't look like many people will be testing it any time soon as everyone smashs the refresh button

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!

Re:Capture the packets

[Anonymous Coward]

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!

Ummmm....No....
You wouldn't SNORT it...You would capture the raw traffic with something like tcpdump or ethereal.

Shhh...

[Anonymous Coward]

The NSA surely wishes to complain about the release of this information.

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.

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.

Re:scope of bug...

[Jonn Carnnack]

I wouldn't assume they aren't affected by this.

If you RTFA you'll see that it states they aren't affected. Only RealVNC is affected, and only version 4.1 (version 4.0 is fine). The Slashdot editors should have titled the article "Critical Flaw Found in RealVNC 4.1", but I guess that would've been not-very-interesting.

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

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

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

[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 bytes affects RealVNC the way it does, it's quite possible that a slight modification to his exploit will affect the others. Better phrasing would've been "Don't assume they're not vulnerable," I suppose. You just shouldn't assume you don't have a flaw simply because a PoC exploit doesn't work against you unless the exploit is understood. Others have been burned this way before. (e.g. PoC works against 2k but not XP, XP is touted as "not vulnerable", someone who understands the flaw finds the right offset and XP is suddenly vulnerable too)

Re:scope of bug...

[Anonymous Coward]

Word!

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 slow because it uses too much CPU (can be seen in taskmanager), but other times it just seems slow because it does not send the update.

Re:scope of bug...

[Anonymous Coward]

I once used the video hook driver back before they reached 1.0 and stopped since it kept causing huge problems in my systems (like BSOD). I'd avoid the video hook driver. The version I'm using is 1.01 and so far it's stable a majority of the time except the few occasions I connect to the machine on a laptop with a weak connection (wireless) and do not get a screen refresh. I also use the DSM encryption plugin. I find it works best to connect to the systems using either LAN or Medium settings over LAN and modem when I'm dialing in.
I've never had a CPU problem.
However, I'll give that POLL FAST fullscreen deactivate a try.
Of the few remote controls systems I've used (Symantec's, MSFT's, VNC's, & WRQ's reflection)
Reflection works really well but costs plenty.
I've used it at both HP and seen it where I currently work.
The nice thing about it is that it works even from the login screen (so that idiot users don't keep typing the wrong idiotic thing).

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 UltraVNC is Windows-only.

Another really nice property of RealVNC is that it has a "reverse connection" mode, where the client listens and the server opens a connection to it (very handy in certain firewall configurations). Finally, RealVNC comes with a "vncconfig" that can be used to adjust configuration on-line, and with a viewer where you can adjust protocol details (bpp, etc) on-line.

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

[Anonymous Coward]

The flaw is a bug in RealVNC _logic_, and not in its _code_ (like a buffer overflow would be). Have a look in realvnc maillist for the description of the problem, you will see why Tight/Ultra are OK.

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?

[gkhan1]

I think (I'm not sure) that the duplicate MAC thing would be a problem, which means that you'd only be able to connect when the other computer is down. That's not the point though, the point is that why bother with MAC-filtering at all? You'd still want to encrypt it using WPA so as to disallow snooping, and if you've done that properly, using MAC-filtering just makes no sense at all.

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 nobody can gain access to this link and have bidirectional communication with the LAN behind it, than that someone might be able to snoop the traffic going across. And I think that will be the case in a vast majority of situations.

Re:encrypted wireless?

[gkhan1]

Look, let me make this as clear as possible. Mac filtering offers NO security. NONE. All your security lies in your WPA key. If someone cracks the WPA key, MAC filtering offers no (NONE) additional security. Whatsoever! Let me say this again, if someone cracks your WPA key, it makes no difference if you have MAC-address filtering. No difference at all.

Adding MAC address filtering to a correctly setup WPA with a strong key is like adding a banana-peel infront of Fort Knox. Sure, I can get past the 30000+ strong army guarding it, but as soon as I get to that vault, I always slip and hurt my head!

Using MAC address filtering as an additional layer of security over WPA is not prudent, it's just moronic.

In fact, it is security-wise much more important that nobody can gain access to this link and have bidirectional communication with the LAN behind it, than that someone might be able to snoop the traffic going across

Fair enough, let me state this as clear as possible. MAC address filtering does not protect your lan in any way except from the occasional neighbor. WPA protects you from the combined forces of all the intelligence community in the world for a billion+ years (and btw, WPA does prtect your lan from outside connections, you have to have the password to connect!) All that, and it's a million times easier to set up! You are just being an idiot.

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 make will be fiercely rejected by the other system (RST replies to all established-state TCP packets that the system does not know about).

I was wondering if a similar thing would go on in a wireless access point. When the two endpoints identify eachother by their MAC, and use this in a similar way to TCP, it would be impossible to join with a new station with the same MAC because any exchanges between the access point and that station would also be received by the legitimate other side, and would result in connection resets, frame rejects, or whatever is appropriate for the linklevel protocol.
This would make it impractical to connect because there is only one allowed MAC and that MAC is defended by the other side of the link. The damage would be limited to a DOS.

You may think that this is ridiculous, but you don't consider the possibility that the entire WPA layer could maybe be disabled because of some still unknown problem in either the protocol or its implementation in certain devices, just like the issue with the VNC server that the parent thread is discussing.
At that point, and additional layer like MAC address filtering could save your system.

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 broken by someone who wants it enough, but OK to keep the casual drive-bys away.

Re:encrypted wireless?

[gkhan1]

Saying WPA "might have a hole" is like saying that AES "hasn't been proven to be completely secure". Technically correct, but really stupid. If WPA is broken (which it wont be, ever) MAC address filtering WILL NOT save your system. Do you even know why it's broken? The thing is, every packet sent to a router will contain the MAC-address of the card that sent it, if you sniff ONE PACKET of data, you can impersonate the sender. A few ARP packets later, and the entire LAN is yours to play with. It's as simple as that.

Look, I don't have the energy to put up a defense of WPA insted of MAC-filtering, simply because it's so ridiculos to do, so I'll just point you to a fun little resource: The Security Now podcast has some great introductions to network security. In episode 11 they explain why WEP and MAC-address filtering sucks. If you want all the details, you can go there. Episode 13 explains why WPA is a quadrillion time better.

Using MAC-address filter is just a plain waste of time and energy.

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 circumvent the WPA using external attacks. When you think that is stupid or ridiculous, you clearly haven't seen anything in the network security world. And you are even posting it in a thread where an application proves to be vulnerable to just such an attack.

When you have learned a bit more, you will know that cracking the encryption algorithm is usually not the only way to attack a system protected by encryption, especially not when it was designed, implemented or is being used by humans.

What do you know about point-to-point wireless links? Not much, obviously. You are thinking that the MAC addresses we are disussing here are card addresses on the LAN, which is obviously something completely different. And even then, you again and again fail to recognize the situation where an attacker might copy the MAC of one of the stations, but then finds himself on the same channel with the rightful owner of the MAC.
This probably will result in extra difficulties. That is what I wanted to ask about. But you obviously are not the correct person to ask.

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

Re:Bottom Line

[Amouth]

/. Sensationalism at it's best :)

Re:Bottom Line

[bconway]

You know there's a difference between something being vulnerable at all and something being vulnerable to a single proof of concept, right?

China no likey

[ezwip]

Talking about exploits can have a negative effect on that company. This might make China unhappy and lead to global nuclear war. Proof positive Slashdot should be banned from all political arenas!

RealVNC

[grub]

TFA says the flaw is in RealVNC 4.1.1 not just VNC. VNC is a pretty broad term nowadays, does it also affect TightVNC, etc?

Re:RealVNC

[grub]

Answering my own question, from this link:

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.

Re:RealVNC

[Anonymous Coward]

You should reply to your own question, not create another thread.

Re:RealVNC

[Anonymous Coward]

He did, change how you view the threads...

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

[Anonymous Coward]

Why the fuck is this modded "Funny"?

Re:OMFG!!

[Spy der Mann]

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

It's called T.V.

Insightful my ass

[Anonymous Coward]

If it says it has to be available from the internet, or it won't be vulnerable. Period. Why the fuck would they go into anymore detail than that? Yours isn't available from the internet, so it's not vulnerable. No "I doubt it" it necessary.

I know people like to have karma points, but for fuck's sake...

Re:Insightful my ass

[Anonymous Coward]

I have to agree, that guy's post was worthless.

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

[Myen]

why need vnc when you have ssh.. who knows..*sigh*

You have VNC when you have SSH because you like to view your desktop remotely. Possibly VNC over SSH.

VNC and SSH solves slightly different, but related, problems. You'd instead drop VNC when you have something like RDP or NX.

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

[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 be an X protocol "mirrorer" that could take everything off of an already running server and mirror it to a nested Xserver on another machine. This would be many orders of magnitue faster and more accurate than VNC.

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

[mysticwhiskey]

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

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?

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.

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

[Anonymous Coward]

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

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 about as well as you can hope over the internet.)

PS. I found a nice little client called DirectVNC which uses the DirectFB (framebuffer) to give you VNC in a console. Since this is for a server type setup, I find it handy since I can have just one X setup running essentially this way. Eg, I don't have to start X to get to the VNC session even. It strikes me that this could also be handy on some minimalistic setups such as some live discs perhaps.

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

[lon3st4r]

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

With ssh, you can log in and export display (over unencrypted TCPIP or tunnel through ssh). Once you have the display exported, you can fire up KMail or whatever else you wish to. You will need an Xserver on your side. If you don't have a window-manager running on your Xserver, you can even start the window-manager session remotely! > But with vncserver + vncviewer, you CAN.

That is true!

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

[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 color depth, etc so works about as
> well as you can hope over the internet.)

For a LAN, I've always believed the following to be faster than directly using the vncviewer on the client:
1. Run Xvnc on the server
2. Run on client, "ssh -X -C server-host vncviewer 127.0.0.1:0"

Instead of directly calling vncviewer and keeping a persistent Xvnc server, you can look at the following to provide multiple logins for a single user, ala Windows Terminal Services: MultisessionX.

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

[Anonymous Coward]

I am a different AC.

What do you suggest people use, oh polite and insightful one?

What about just "Unix"? Everybody will still know what you mean. What's the point of just stripping "U" and replacing it with "*"? You are not shortening it anyway.

Is there another one ending with nix, (apart from Xenix and Minix, which are maybe the less-important variants)?

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

[Marlow the Irelander]

I understand that the actual reason for using "*nix" is not wildcarding, but instead because UNIX is a trademarked term. *nix is just some self-censorship to talk about it freely, or probably a protest against trademarking for some people.

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

[Nazo-San]

From what I can tell, that does look like a good solution. Particularly if you are going for a thin client setup (eg a PC with just a CD-ROM, a USB flashdrive, or even just PXELinux or something like that.) Part of what I like about my current setup though is that I can leave the same session open and connect to it from a remote system. The other day this was a bit of a lifesaver because I needed to get to a site that used a port that was blocked on the school computers. By connecting to the server on my own system (which I had carefully picked a port I knew wasn't blocked for) I was able to use a graphical client (the page was very heavy in images and using lynx/links got quite unpleasant at best.) I had also hoped to set up port forwarding to even connect through my ssh session to my main PC which runs Windows where I could then do things like image editing, but, I never quite got that working for some reason (don't know if I need that anymore anyway.)

Thanks for the info though. Every now and then I actually wonder if some people I know might be better served with really cheap thin clients. It's more of a what-if mental excercise than an actual plan, but, who knows, maybe someday I'll be digging frantically for this post in the archives. ^_^

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

[GiMP]

The solution I posted DOES let you leave the session open and connect from a remote system. A vnc server is used to keep the session running, but the client connects via X11 instead. The only thing required on the client-side is an X11 server. If you need a web-based solution, WierdX will do the job.

My posted solution, however, improves on the idea by allowing you to create and manage multiple sessions for multiple users! It can automatically create new sessions if a user logs in more than once. If multiple sessions are found, on login, a menu is provided giving a list of active sessions.

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

[Nazo-San]

What I'm saying is VNC is better at remote stuff. A, you only need a VNC client which has several major binaries (including windows, which is what I need) and a Java version (for emergencies,) and B, you get control over compression level, control of the level of JPEG compression, etc. And the X11 client on windows just wouldn't be fun. Oh, and I've tried the kinds that do the HTTP sessions. Didn't like the way that worked.

Your solution is better for a LAN only configuration. The other way I'm using is just the best you can do with remote, which isn't saying much -- especially when the server is behind an ADSL modem, but, which is all you can really do to get it as close to running smoothly as possible. Besides, it's really just a single user system and I don't really need, nor want, to manage multiple sessions but want just a single session (all the stuff I do where a second session would help, I need only a console to do and a GUI would just slow me down.)

Nothing personal, just this is what works best for situations like mine.

Re:The penultimate Slashdot troll post investigati

[jihadi_diggrulz]

Mod parent up +5 Insightful.

Just my €0.01.

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.

Re:The penultimate Slashdot troll post investigati

[Anonymous Coward]

and you bit! and so did i! brilliant, chibi! kudos.

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 accept the risk that come with security holes like these, plaintext passwords, and even man in the middle attacks that allow the attacker to view the desktop during an active session. Basically, weak security has gotten even weaker.


P.S. They have a neat little prog that will test your computer to see if it is vulnerable, though it is currently disabled because "Slashdot is too much for it to handle."

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 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. Even plain text passwords can be pretty secure (as long as they are quite large, and not many can be tried in a short time interval).

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.

Re:OS X Affected?

[JD-1027]

Yep, OS X supports VNC in the sharing control panel without any special software. In the newest system there is a checkbox in the remote desktop sharing that says "Allow connections via VNC" with a password box. It works great with multiple VNC clients. I couldn't believe my eyes when I connected to control my Mac from a PC and it worked!

All I had to do was check a box in OS X that said allow VNC connections and set a password. No special VNC server software or anything, it was very cool to have that as part of the default OS and soooo simple to turn on.

Which is why...

[SpiritGod21]

I use TightVNC.

ssh man

[paulsomm]

exactly why my VNC server only responds to localhost connections and I tunnel the connections in through ssh.

Well, not exactly why. not like I knew this particular exploit existed . . . but its why i only use ssh and terminal services over an ssh tunnel, 'cause you never know.

now if an exploit for openssh comes about allowing access without the publickey/private key, I guess I'm hosed . . .

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

[tarka69]

... And obviously replace your hostname with mine

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

[Anonymous Coward]

you sure are brave posting your vnc4 server address on slashdot... unless it's an altruistic offer of your pr0m stash to the needy?

Seriously though, I sure hope you only accept connections from known hosts (key verified) and your login is not admin:password ;)

cheers

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

[tarka69]

Yes, a silly mistake, but ultimately it doesn't make any difference as any host on the internet is scanned and attacked all the time.

Still, gives me an incentive to re-check my configuration.

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

[ars]

".. And obviously replace your hostname with mine"

I think you got that backward.

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

[Anonymous Coward]

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

For those that don't know, patches for CallManager are only supported for installations using either the terminal, VNC, or Ultra VNC. Patch installation is not supported using Remote Desktop.

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

[lukas84]

That's why you have bought an IP KVM Switch.

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, wouldn't they?

This is a fake!!!

[Anonymous Coward]

Wake up. This is fake. Kudos for giving this shitty company free press.

Thank you.

[CFD339]

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

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.

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 another open to help, or even share the workspace. This is much efficient.

Hello Slashdot, could someone explain what VNC is?

[Anonymous Coward]

I know I can find the answer with Google, but would it be unreasonable to put in some explanation, or maybe a link, when you use acronyms that not everyone will know? In the case of VNC, it is not something which eveyrone uses or is aware of.

----------
Diesel car forum - coming soon

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.

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

[mshmgi]

I think it's intended use is only on local networks when you're behind a firewall

ARD lets you connect from anywhere.

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

[lucidsystems]

If you create an SSH tunnel to the machine with ARD running, then you will be able to connect to that machine, via the SSH tunnel. We would reccomend ussing SSH to secure any remote control such as ARD. If you would like help setting this up, then contact : Lucid Information Systems

While I hate to say it...

[Khyber]

Just releasing a stable patch for it and saying it's just a bad database overflow would probably be better than disclosing proof of concept, especially if it can be run on other machines, particularly DEFENSE NETWORKS THAT SHOULDN'T BE ON THE INTERNET ANY-FUCKING-WAY LIKE THEY ARE NOW. Excuse me? Our original DARPA-NET still connected to the rest of the world? What? Can you please explain this to me, even IF it is funded with taxpayer dollars, please? *SOME* info has to remain sensitive, and I'm a huge 4th amendment advocate. Besides the point, some of our own info *MUST* remain private if we, as a country, are to have/maintain our own self-independence. Let's just not make sure it comes to Bushism/Catholicism/Ninjitsu/WHATEVER RELIGION PERIOD.... ONLY rational and realistic thinkers are allowed, with SOME exception for those that *MAY* have half a clue, unlike everyone else, who seems uneducated. Think I'm talking about you? Check your current school discrict grades with other school districts. Do I hear an "I'm sorry?"

Our schooling system, before anything else, needs a reform. If you ask me "How do you propose this, Sir?" I point you to my previous posts. Since my Firefox copy/paste function is inexplicably broken, I invite you to search through my most recent TEN slashdot posts I've made, and within those, you'll find the relevant answer that I believes answerss your question/s.

Re:While I hate to say it...

[Anonymous Coward]

What the hell are you babbling about? Does your guardian know your out of your hutch? Is your mommy home? Can I speak with your mommy?

Re:tight vnc (NOTE TO MODERATORS)

[julesh]

Mods, the parent post is *not* offtopic. It's an important question, the answer to which is "no, it isn't.".

Re:tight vnc (NOTE TO MODERATORS)

[julesh]

Erm... "yes, it is."

Note to self: proofread post before posting.

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.g. intelligent KVM switches) because it has encryption built in.

Note that RealVNC is not really open source; its more advanced features are under other licenses.

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 you can just do it the old fashioned way, via SSH, or even better - NOT LEAVE PLAINTEXT-PROTOCOL SERVERS RUNNING ON INTERNET-CONNECTED PC'S. You wouldn't run telnet on your parent's machine, don't run VNC without some sort of encryption.

Is TightVNC dead?

[Anonymous Coward]

It's been almost a year since the latest release and there are a number of bugs (particularly the annoying 'disconnecting' bug) that have not been fixed yet, even though they have been around for a while. If it wasn't for the built-in file transfer feature (which I can't live without) I would have dropped it a while ago. Anyone knows any VNC flavor with built-in file transfer feature, besides tightvnc? also, is tightvnc really dead???

Re:Is TightVNC dead?

[funfail]

UltraVNC has file transfer, too.

Re:Is TightVNC dead?

[sshutt]

We're using ultraVNC here,has a few nice addons, apeares to be windows onle binaries, they also have a load of links to other VNCs

Faster than Light

[Anonymous Coward]

Refering to This slashdot post...

If VNC could utilize this technology and get the info to go faster than light, and I manage to VNC 127.0.0.1, would I be able to get my work done before I do it?

This would be cool...
</offtopic>

Was anyone able to see the screenshot

[Anonymous Coward]

I tried it with RealVNC 4.1, yesterday. They told me I was not vulnerable. So I thought maybe this company is claiming this just for the publicity and let it go.

Since it made it on Slashdot frontpage, maybe there is something more to it that I am missing (there's always hope for slashdot editors, I am a pessimist). Was anyone able to see their desktop over this website?

On a sidenote, whoever created captchas that are so hard to read like this one I am seeing on the screen right now, should be hung by their balls and shot.

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.

My safe?

[Anonymous Coward]

If it says your safe - then hey your safe.

I don't understand how VNC could pass back details of my safe, it is nowhere near my computer!

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

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:Point taken, and very true, but please...

[gkhan1]

I mostly agree, his WMF-thing was just ridiculous, but the Security Now podcasts are rather good if you are not to experienced in computer security related matters. They are informative, fairly comprehensive, and not too advanced.

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

VNC has never been known...

[Anonymous Coward]

...to be "secure" at all, anyways. It was never intended to be "secure" it was intended to simply provide convenient remote-control access of a desktop with no semblance of security ever implied.

RealVNC 4.1.2 released

[staplin]

RealVNC has already released a 4.1.2 update 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.