Slashdot Mirror


Critical Flaw Found in VNC 4.1

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

12 of 175 comments (clear)

  1. SSH by Anonymous Coward · · Score: 5, Insightful

    You should tunnel unencrypted services like VNC over SSH anyway.

    1. Re:SSH by Anonymous Coward · · Score: 2, Insightful

      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.

  2. Not enough details by Raleel · · Score: 2, Insightful

    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.

    --
    -- Who is the bigger fool? The fool or the fool who follows him? --
    1. Re:Not enough details by AirLace · · Score: 1, Insightful

      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.

    2. Re:Not enough details by micheas · · Score: 2, Insightful
      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.
  3. Yikes! by timeOday · · Score: 5, Insightful

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

  4. Slashdoted by Amouth · · Score: 1, Insightful

    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

    --
    '...if only "Jumping to a Conclusion" was an event in the Olympics.'
  5. SSH tunnels by ArbitraryConstant · · Score: 5, Insightful

    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.

    --
    I rarely criticize things I don't care about.
  6. Company sells remote control software by srh2o · · Score: 3, Insightful

    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.

  7. OS X Affected? by wo1verin3 · · Score: 3, Insightful

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

  8. Re:SSH Port forwarding by redcane · · Score: 2, Insightful

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

  9. Re:VNC is an important tool by birder · · Score: 2, Insightful

    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.