[17725] in bugtraq
Re: WinVNC 3.3.x
daemon@ATHENA.MIT.EDU (Chris Wolfe)
Tue Nov 21 14:36:44 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <4.1.20001121103305.00a64f10@qlink.queensu.ca>
Date: Tue, 21 Nov 2000 11:28:00 -0500
Reply-To: Chris Wolfe <9cw4@QLINK.QUEENSU.CA>
From: Chris Wolfe <9cw4@QLINK.QUEENSU.CA>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <3.0.5.32.20001120125900.013db798@pop.mindspring.com>
Since no one with a closer affiliation to the VNC project seems to want to
respond, I will try to clear up some of the confusion. I am not a developer
on the project, but I have built a partial implementation of the protocol
and have worked through parts of the WinVNC source code.
The password stored in the registry is encrypted with a fixed key. Because
of the MD5 challenge-response authentication this password must be
decryptable by the server, and so can not be stored hashed. This MD5
challenge-response architecture is very often used for simple encrypted
authentication, and the fixed-key encryption is even more common.
The password is not sent over the network in the clear, and is not
length-restricted by the protocol. The issue of password length has been
raised before in the VNC mailing list, and generally seems to be considered
a bug (though no one has AFAIK fixed it in the standard Windows version).
Brute-forcing the passwords is relatively difficult: requiring either
sniffing the network and brute-forcing the MD5 offline, or repeated
connections to the server. Based on my interpretation of the source code I
have (WinVNC 3.3.3) a client may only attempt to authenticate once every
ten seconds, which makes brute-forcing the password very time consuming.
Instructions on using VNC through SSH are linked from the VNC FAQ, and a
few places in the documentation. Refering to
<http://www.uk.research.att.com/vnc/sshvnc.html> should be substantially
easier for most people than acquiring a book.
I will pass these concerns to the VNC mailing list as I have not seen any
discussion of NT registry permissions. VNC is open-source, so you are very
welcome to contribute a patch to fix the NT security problems -- remember
the same distribution has previously been used for both NT and 9X systems.
VNC Homepage: <http://www.uk.research.att.com/vnc>
Cheers,
Chris
At 12:59 PM 11/20/00 -0800, David LeBlanc wrote:
[snip]
>Something that I think is really important to point out is that it is the
>developer's responsibility to set permissions on new things that they
>create. The defaults that you inherit from the parent keys are meant to
>allow nearly anything to work, but isn't appropriate for passwords, or
>anything else that's sensitive.
>
>However, VNC doesn't seem especially interested in security - that's why
>passwords are limited to 8 characters and are fairly crackable. It's why
>the information travels in the clear. This particular application is such a
>menace to security that we strongly discourage its use at work.
>
[snip]
>this also depends on who you
>want to be able to USE VNC - I'd bet that they require anyone using it to
>have access to these keys. Also not an especially wonderful thing from a
>security standpoint.
>
[snip]
>
>A better fix is to use something more secure. Another fix detailed in
>Stephan Norberg's new book from O'Reilly is to tunnel VNC though ssh, or if
>you have Win2k, wrap the whole thing in IPSec. And fix the registry
>permissions - also check the file system permissions, as I'd bet they do
>the same thing there.
>
>
>David LeBlanc
>dleblanc@mindspring.com
