Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Critical Flaw Found in VNC 4.1 175

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"
This discussion has been archived. No new comments can be posted.

Critical Flaw Found in VNC 4.1

Comments Filter:
  • SSH (Score:5, Insightful)

    by Anonymous Coward on Thursday May 11, 2006 @08:45PM (#15314511)
    You should tunnel unencrypted services like VNC over SSH anyway.
    • Re:SSH (Score:2, Informative)

      by merryberry ( 974454 )
      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.
    • 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
      • 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
        • 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.
          • 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
      • by snol ( 175626 )
        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
      • 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.

  • Not enough details (Score:2, Insightful)

    by Raleel ( 30913 )
    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.
  • Yikes! (Score:5, Insightful)

    by timeOday ( 582209 ) on Thursday May 11, 2006 @08:47PM (#15314519)
    Surely inspection of the vulnerability test will betray the flaw to attackers?
    • Re:Yikes! (Score:2, Interesting)

      by alexmipego ( 903944 )
      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.
      • 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.

    • Don't worry, we've slashdotted their server already :)
  • tight vnc (Score:3, Interesting)

    by bazooka_foo ( 640901 ) on Thursday May 11, 2006 @08:52PM (#15314539) Journal
    i guess tight vnc is okay??

    that is what I use
  • SSH tunnels (Score:5, Insightful)

    by ArbitraryConstant ( 763964 ) on Thursday May 11, 2006 @08:53PM (#15314549) Homepage
    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 (Score:5, Informative)

    by a_greer2005 ( 863926 ) on Thursday May 11, 2006 @08:54PM (#15314550)
    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... (Score:5, Informative)

    by AmigaAvenger ( 210519 ) on Thursday May 11, 2006 @08:55PM (#15314559) Journal
    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... (Score:2, Informative)

      by ImaLamer ( 260199 )
      Except for encryption, but this makes encryption worthless.

      It's all the same.
    • This bit of information was useful to know, and didn't make the /. summary.
    • Re:scope of bug... (Score:4, Interesting)

      by petard ( 117521 ) * on Thursday May 11, 2006 @11:57PM (#15315405) Homepage
      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... (Score:4, Informative)

        by moonbender ( 547943 ) <moonbender AT gmail DOT com> on Friday May 12, 2006 @04:04AM (#15316076)
        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.
        • 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... (Score:5, Interesting)

      by pe1chl ( 90186 ) on Friday May 12, 2006 @02:12AM (#15315825)
      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.
      • 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...
      • 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
        • 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
    • 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.
    • 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

  • 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?
    • by 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).
      • 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?
      • 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

  • From the initial article preceding the proof of concept, TightVNC, UltarVNC and RealVNC 4.0 are not affected.
  • Bottom Line (Score:5, Informative)

    by bogie ( 31020 ) on Thursday May 11, 2006 @08:58PM (#15314573) Journal
    "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.
    • 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!! (Score:2, Funny)

    by LoztInSpace ( 593234 )
    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)
  • by layer3switch ( 783864 ) on Thursday May 11, 2006 @09:19PM (#15314680)
    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.
    • > 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
      • by mhesseltine ( 541806 ) on Thursday May 11, 2006 @11:48PM (#15315366) Homepage Journal
        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.
  • by srh2o ( 442608 ) on Thursday May 11, 2006 @09:32PM (#15314740)
    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.
    • 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? (Score:3, Insightful)

    by wo1verin3 ( 473094 ) on Thursday May 11, 2006 @10:01PM (#15314887) Homepage
    Can anyone check to see if OS X's implemtation of VNC (desktop sharing) is vulnerable?
  • 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.
    • 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.

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

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

  • 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.
    • by 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.
  • 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... (Score:3, Informative)

    by Idaho ( 12907 ) on Friday May 12, 2006 @02:40AM (#15315899)
    ...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... (Score:3, Informative)

      by ledow ( 319597 )
      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 (Score:3, Informative)

    by porkface ( 562081 ) on Friday May 12, 2006 @05:45AM (#15316258) Journal
    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.
  • by sl4shd0rk ( 755837 ) on Friday May 12, 2006 @06:36AM (#15316358)
    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 has already released a 4.1.2 update [realvnc.com] that closes the vulnerability.
  • 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?
  • 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.

You can tune a piano, but you can't tuna fish. You can tune a filesystem, but you can't tuna fish. -- from the tunefs(8) man page

Working...