mailing list archives
Re: WinVNC 3.3.x
From: Chris Wolfe <9cw4 () QLINK QUEENSU CA>
Date: Tue, 21 Nov 2000 11:28:00 -0500
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>
At 12:59 PM 11/20/00 -0800, David LeBlanc wrote:
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.
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
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.
dleblanc () mindspring com