VNC zlib Advisory draft 1

Andrew van der Stock ajv "at" greebo.net
Thu, 14 Mar 2002 11:42:13 +0000


Yep - only the client should be affected by this, and we do not suffer
at all from the other gzip vulnerability (long filenames > 1028
characters).

The prerequisites required to allow this exploit are:

* the server must be capable of using zlib for encoding
* you must logon and authenticate to that server 
* your client must be capable of decoding a zlib encoded sequence
* that server must send you the duff stream (not impossible, could be
injected in the stream (advanced players only, and even then it's
unlikely as they can simply watch the stream and learn your credentials
- far more useful))
* you must have a malloc()/free() implementation that acts in roughly
the same way as Linux's glibc does

Once the double free occurs, the fault might be able to cause a heap
overflow, but if you're using a lesser used platform it may be
impossible to cause any real harm. But on platforms like MacOS where the
equivalent of a segv might cause the entire OS to halt it would be best
if we just fixed it. I understand that MacOS 9 is a lot better at
stopping this, but when I last used MacOS, it was the 7.6 days and the
early part of MacOS 8, and I had MacsBug come up quite a lot. (Yes, I'm
a Mac lover with two MCSE's. I've had four so far, and the new iMac has
a place in my new home once the new financial year ticks over)

At least it's not a server-side compromise - on NT that would have been
a nightmare! :-)

Thanks,
Andrew

-----Original Message-----
From: owner-vnc-list "at" uk.research.att.com
[mailto:owner-vnc-list "at" uk.research.att.com] On Behalf Of Jonathan Morton
Sent: Thursday, 14 March 2002 9:51 PM
To: vnc-list "at" uk.research.att.com
Subject: RE: VNC zlib Advisory draft 1

If it's only inflate that's faulty, doesn't that exclude all current 
VNC servers from the vulnerability?  They only deflate, not inflate. 
Of course, it also changes the severity of the vulnerability 
significantly - the exploit happens on the viewer end, which is often 
more useful than on the server end, and an attacker need only be able 
to modify the stream going back to the viewer.

[snip]

Yes, and fixing that bug is always good whether it closes a hole or 
not.  The hole just makes it more urgent.
---------------------------------------------------------------------
To unsubscribe, mail majordomo "at" uk.research.att.com with the line:
'unsubscribe vnc-list' in the message BODY
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------