VNC Security Bulletin - zlib double free issue (multiple vendors and versions)

["Andrew van der Stock" <ajv () greebo net>]

              VNC Security Bulletin - zlib double free issue 
              
                          3 April 2002 - Release

            zlib double free may cause local exploit or crash

Impact
======

Low risk - potential VNC Viewer (client side) exploit 

An attacker may be able to execute arbitrary code/commands as the 
user of an affected VNC Viewer.

No VNC server or client is affected by the gzip long filename issue. 

Fault trigger prerequisites
===========================

* A zlib-capable VNC server;

* A zlib-capable VNC viewer must successfully log on to the above
  zlib-enabled VNC server;

* The server must send the faulty stream - requires a very specific
  stream injection or a trojaned server; and

* The VNC viewer's operating system or libc implementation must have a 
  memory allocator that behaves in roughly the same fashion as GNU 
  libc's malloc()/free() in a double free situation.

Mitigating factors

* VNC viewers using RFB 3.3 cannot send any details about their 
  processor (native code) or virtual environment (Java) to the server,
  so exploit stream injections will have to assume a particular
  platform to trigger the bug; 

* It is not possible to find affected viewers in an automatic way; 

* Some of the affected viewers do not implement "listen" mode; and

* The multitude of different platforms, service packs, patches, and 
  widespread differences in various Unix implementations makes a 
  universally workable exploit unlikely.
 
The fault will generally crash the VNC viewer, making it fairly obvious 
something bad happened. There are no known trojaned VNC servers known at

the time of writing, however this is not an absolute.

Although the above points fail the "#1 lamest excuse" - "No one will do 
that!"- from the excellent "Writing Secure Code" book by Howard and 
Leblanc (p 453), it is a fairly unlikely set of conditions to meet and 
therefore we believe that it will affect few users.  


Affected versions 
=================

The following list is not comprehensive, but does represent the vast 
majority of all zlib-enabled VNC viewer clients in active use or 
development. 

The following VNC viewers ARE vulnerable and should be upgraded:

* TightVNC viewer prior to version 1.2.3
* TridiaVNC viewer prior to version 1.5.6 (Win32)
* TridiaVNC Pro viewer prior to version 1.2.00 (Win32)
* TridiaVNC Unix viewers upto and including version 1.4.00
* VNCThing prior to version 2.3 for Mac OS 8/9/X
* VNC Viewer and Server for Apple Newton
* VNC Viewer for Java - the JRE / browser is the problem

Unaffected versions:

* AT&T VNC - any past or current viewer on all platforms, including
  Win32, Xvnc, and the beta WinCE 
* TightVNC 1.2.3 or later
* ChromiVNC v3.4 alpha 5 for MacOS (68k and PPC platforms)
* VNCThing 2.3 or later
* TridiaVNC viewer 1.5.6 and later (Win32)
* TridiaVNC Pro viewer 1.2.00 and later (Win32)
* Geos (Nokia 9000) VNCGEO10
* OS/2: VNC Viewer for OS/2 PM 1.00
* PalmOS: PalmVNC 1.40
* RiscOS: !VNC (any version)
* VMS: AT&T VNC VNC333R1VMS011 package

Unknown at this time: 

* IBM AIX 4.3.3 and 5L, "Toolbox for Linux applications" (based upon
  AT&T?)

Resolved:

* TightVNC 1.2.3 is available as of this posting. All users of 
  TightVNC are strongly encouraged to upgrade. 

* VNCThing 2.3 should be available around the time of this posting. 
  All users of VNCThing should upgrade as soon as it is available. 
  
* TridiaVNC 1.5.6 (Win32) should be available shortly. All users of 
  TridiaVNC should upgrade to 1.5.6 as soon as it is avialble. 
  
* TridiaVNC Pro 1.2.00 (Win32) is now available. All users of 
  TridiaVNC Pro (Win32) should upgrade to 1.2.00


Discussion
==========

There is a vulnerability in the decompression algorithm used by the 
popular zlib compression library. If an attacker is able to pass a 
specially-crafted block of invalid compressed data to a VNC Viewer 
that includes zlib, the viewer's attempt to decompress the crafted 
data can cause the zlib routines to corrupt the internal data 
structures maintained by malloc.

Various VNC implementations use the affected versions of zlib. This 
could lead to execution of arbitrary code under the privilege the user 
of the client program utilizing gzip, which is generally the local 
user in Unix (which may include root), and the local user or 
Administrator in WinNT/2000/XP, or complete control of platforms 
without a security architecture (MacOS prior to MacOS X, Win95 - 
WinME, WinCE, Newton, etc).


Technical Details
=================

Please view the following CERT advisory: 
http://online.securityfocus.com/advisories/3955


Solutions and Workarounds
=========================

If you have an affected viewer, the following will help reduce the 
risk even further:

* Use the lowest privilege user possible when using VNC viewers;
* Connect only to servers you trust - disconnect immediately if you do
  not believe the server to be genuine; 
* Do not use VNC viewer "listen mode";
* If you are running an affected viewer, upgrade at the earliest
  opportunity.

Some Unix versions of affected VNC viewers utilize the zlib shared 
library, libz.so. Upgrading zlib should remedy some Unix platforms. 

Mac OS applications running on Mac OS 9.x or earlier use several 
layered memory allocators, as do Carbon CFM applications running on 
Mac OS X, and so are unlikely to be affected. Revision of the viewers 
for MacOS and MacOS X will be made in due course. 

Java viewers and servers rely on the Java Runtime Environment (JRE) 
and/or the client browser being correct. To correct Java-related 
problems, please review the appropriate advisories for Java Runtime 
Environment and/or your browser.


Vendor responses
================

ChromiVNC

Jonathon Morton writes: "ChromiVNC does not yet implement the Zlib 
encoding, and thus does not include the Zlib library. Please remove it 
from the list of affected products. When Zlib is implemented, I will 
use the latest version of the library available at that time."

VNCThing

Dair Grant writes: "The next version of VNCThing (2.3) will be linked 
with zlib 1.1.4: should be available fairly soon."

TightVNC

Constantin Kaplinksy writes: "This issue is fixed in the newly 
released version, 1.2.3. The source and binary archives are available 
at the usual place: http://www.tightvnc.com/download.html";  

Tridia

Brian W. Blevins writes: "Thank you for tracking the zlib 
vulnerability in the various VNC releases so thoroughly! Tridia has 
released version 1.2.00 of our TridiaVNC Pro product with zlib 1.1.4 
in both the WinVNC server and vncviewer. We have updated the Win32 
sources on the CVS server with the new zlib implementation for 
TridiaVNC version 1.5.6.  However, there is not yet a new binary 
release of TridiaVNC for Win32 at this level. The various Unix based 
TridiaVNC binaries are at level 1.4.00 and the viewers in those 
releases remain vulnerable.  We have not yet updated the Unix sources 
on the CVS tree. We will include the zlib 1.1.4 implementation in 
subsequent binary releases when those become available."


Thanks To
=========

* Jonathan "Chromatix" Morton (ChromiVNC) - good feedback on the first
  draft and vendor statement. 
* Dair Grant (VNCThing) 
* Constantin Kaplinksy for responding with a fixed version before this
  advisory was released.
* Brian W. Blevins for his update for TridiaVNC. 

Revision History

2002-03-15 First draft
2002-03-22 Second draft
2002-03-23 Changes to second draft
2002-03-25 Release candidate
2002-04-03 Updated with Tridia information
2002-04-03 Posted to bugtraq. 


More Information

An up-to-date of this release will be maintained at 
http://www.evilsecurity.com/vnc/vnc-zlib-advisory-02.htm. 

Copyright (c) 2002, Andrew van der Stock et al. All Rights Reserved. 
Permission to reprint redistribute this advisory whole is granted as 
long as this copyright notice stays intact. Andrew van der Stock 
disclaims any liability for the use or misuse of the information 
presented here, and does not warrant for the accuracy or veracity of 
any of the claims made above, particularly the bits by the vendors :-) 
The statements by the vendors are (C) their respective authors and 
would more than likely also disclaim any liability from the 
information provided.