Re: WinVNC 3.3.x

[Chris Wolfe <9cw4 () QLINK QUEENSU CA>]

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