Win32 API 'shatter' vulnerability found in VNC-based products

["EXT-Bellers, Chris" <chris.bellers () boeing com>]

Win32 API 'shatter' vulnerability found in VNC-based products

CONFIRMED PROGRAMS:

VNC v3.3.3R9
TightVNC v1.2.5
TridiaVNC 1.5.4

SUSPECTED PROGRAMS:
TridiaVNC Pro
All other VNC-based remote console products


EXPLOIT TYPE:
'Shatter'-type win32-based local privilege escalation
(See: http://security.tombom.co.uk/shatter.html for details)


SCOPE:

Any Win32 system with VNC-based software installed, and interactive logon
access. While this is technically a local exploit, it can be done through
a VNC session (In my tests the VNC process died after spawning
the shellcode, which would certainly end the VNC session (But not the 
shellcode, which stayed functional)).


SUMMARY DESCRIPTION:

After reading up on the 'shatter' class of Win32 API exploits discovered
by Chris Paget (aka Foon), I decided to see what other programs
immediately leapt out at me as being potentially vulnerable. Staring out of
my system tray was my beloved VNC logo.

Applying Mr. Paget's  exploit as described in the white paper resulted in
a LocalSystem command shell on both NT 4 and Win2K systems (with current
Service Packs). I lacked an XP box for the purposes of this demonstration,
but I see no reason that XP would be immune.

Further testing revealed that the VNC-derivative products TightVNC and
TridiaVNC are also vulnerable via the same process.
I suspect that all currently available VNC-derived code is vulnerable.


EXPLOIT REQUIREMENTS::

1. Windows machine A has VNC service installed (for remote access, remote
helpdesk, etc etc)
2. Hostile user has some sort of account allowing local access, such as
Guest or normal user account. In my demonstration, I used both
unprivileged local and Active Directory accounts.


TECHNICAL DETAILS:

Please consult Chris Paget's white paper concerning the Shatter class of 
Win32 API vulnerabilities at http://security.tombom.co.uk/shatter.html 
for a much more thorough treatise on the perils of interactive services
being owned by LocalSystem than I could ever hope to write.
The only pertinent info to be added is that the "Add new clients" dialogue
box was used to send the shellcode. To demonstrate this oneself, simply
s/NAV/VNC in the Paget document.


VENDOR STATUS:

Multiple VNC developer lists were consulted recently. Every
response received to date has been "VNC is not a good tool to use when
local access is granted to users".

This seems a fine reply for servers, where only trusted users are given
physical access or  interactive logons, but  VNC is used in many 
workstation environments for remote helpdesk applications.

Tridia repeatedly told me to buy TridiaVNC Pro which, while admirably 
supporting SSL/TLS, does little to address this problem. If the user 
can log on interactively, the game is over.

As of the time of this alert, I had not been told any efforts were being
made to separate privileged service code from user-accessible system tray
code by any developers.


EXPLOIT STATUS:

Unpatched, unresolved, and most likely in the wild as soon as the kids
finish reading.


CREDIT:

Chris Paget, for giving win32 developers their very 
own sprintf() to worry about.

Keith Morgan from Terradon Communications, for keeping
me from writing a bad vulnerability report.





Chris Bellers 314.233.7181
OSA System Administrator
Boeing, Phantom Works