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.
This archive was generated by hypermail 2b30 : Tue Apr 02 2002 - 22:41:50 PST