full-disclosure - RealVNC 4.1.2 minor heap corruption/DoS vulnerability (authentication required)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Sat, 19 Aug 2006 09:30:56 +0100
From: Niall FitzGibbon <fitzgibbon@...eyonder.co.uk>
To: full-disclosure@...ts.grok.org.uk
Subject: RealVNC 4.1.2 minor heap corruption/DoS
	vulnerability (authentication required)

This vulnerability affects the latest version of RealVNC (4.1.2) on all 
platforms.  It is tested on Windows.

To exploit the vulnerability, the attacker must either control a connected and 
authenticated client connected to a vulnerable VNC server or control a VNC 
server with at least one vulnerable connected and authenticated client.

The attack exploits a signed/unsigned integer mismatch leading to an integer 
overflow and subsequent allocation of very large or zero size areas on the 
heap.  The result of the attack is Denial of Service due to heap corruption 
and improper program flow.  It doesn't seem possible to exploit the heap 
corruption in order to gain code execution the source of the copy operation 
is not defined by the attacker.  The attack is thus of limited usefulness due 
to the necessity of prior authentication.

The vulnerability lies in the following functions:
rfb/SMsgReader.cxx : readClientCutText()
rfb/CMsgReader.cxx : readServerCutText()

These functions handle clipboard changes propagated from the other party.  The 
simplest way to trigger this vulnerability is to modify the 
CMsgWriter::clientCutText or SMsgWriter::writeServerCutText in order to send 
an integer length of -1 on clipboard updates.  This results in an allocation 
of zero bytes to the heap on the other party and subsequent write of a zero 
terminator to an address immediately before the allocated zero-length buffer 
followed by a large memcpy to that buffer.  When an exception is finally 
thrown, RealVNC handles this by terminating the connection and possibly the 
process, throwing an error message about the message type.

Reported to vendor (v4bugs@...lvnc.com) 01 August 2006.  No response at time 
of writing.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/