RE: libvnc and tightvnc vulnerabilities

[Pavel Cheremushkin <Pavel.Cheremushkin () kaspersky com>]

Thanks for an answer. 

> This one is interesting in that related server-side code got some scrutiny before, yet apparently this similar issue 
> in its client-side counterpart was overlooked.  (I assume this is in libvncclient/rfbproto.c, and you meant line 
> 2220, not 1220.)

These particular issues I was describing in my previous letter are located in source code of TightVNC vncviewer. Source 
code of TightVNC 1.3.10 vncviewer can be acquired though this link 
https://www.tightvnc.com/download/1.3.10/tightvnc-1.3.10_unixsrc.tar.gz and integer overflow that leads to a 
heap-buffer-overflow I was speaking about is located on the line 1220 inside file `vnc_unixsrc/vncviewer/rfbproto.c`. 
It is a fun fact that inside `libvncclient/rfbproto.c` the same code is located on line 2220, but all bugs connected 
with LibVNC I described in Github issues inside LibVNC repository.

Best Regards,
Pavel Cheremushkin
Security Researcher| ICS CERT Vulnerability Research Group | Kaspersky Lab
39A bld.2 Leningradskoye Highway, Moscow 125212, Russia | www.kaspersky.com,www.securelist.com


-----Original Message-----
From: Solar Designer [mailto:solar () openwall com] 
Sent: Monday, December 10, 2018 6:40 PM
To: Pavel Cheremushkin <Pavel.Cheremushkin () kaspersky com>
Cc: oss-security () lists openwall com
Subject: Re: [oss-security] libvnc and tightvnc vulnerabilities

On Mon, Dec 10, 2018 at 12:48:43PM +0000, Pavel Cheremushkin wrote:
> 2. heap buffer overflow in rfbServerCutText handler
>     Heap buffer overflow in `rfbServerCutText` handler inside `HandleRFBServerMessage` happens due to the malloc 
> argument unsigned integer overflow on line rfbproto.c:1220. Suppose msg.sct.length equals 0xffffffff, then 
> `malloc(msg.sct.length+1);` = `malloc(0);` will allocate small heap chunk of size 0x10. But `msg.sct.length` = 
> 0xffffffff bytes may be read in this chunk on line 1222 (`ReadFromRFBServer(serverCutText, msg.sct.length)`).

This one is interesting in that related server-side code got some scrutiny before, yet apparently this similar issue in 
its client-side counterpart was overlooked.  (I assume this is in libvncclient/rfbproto.c, and you meant line 2220, not 
1220.)

Specifically, the oCERT advisory from 2014 based on "vulnerability report received from Nicolas Ruff of Google Security 
Team":

https://www.openwall.com/lists/oss-security/2014/09/25/11
https://ocert.org/advisories/ocert-2014-007.html

"A malicious VNC client can trigger multiple DoS conditions on the VNC server by advertising a large [...] 
ClientCutText message length [...]"

Per this wording, there was no integer overflow potential in the server-side code.  Just potentially maliciously large 
allocation.

This reminds us now: in the client-side code, we should also deal not only with the integer overflow potential, but 
also with potentially maliciously large allocation.

The thread I started earlier this year:

https://www.openwall.com/lists/oss-security/2018/02/18/1

"LibVNCServer rfbserver.c: rfbProcessClientNormalMessage() case rfbClientCutText doesn't sanitize msg.cct.length"

I did not look at the VNC client code as it was not relevant to the security audit I was working on when I found the 
server-side issue.

Alexander