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]
Message-Id: <200608190930.56858.fitzgibbon@blueyonder.co.uk>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ