Re: libvnc and tightvnc vulnerabilities

[Solar Designer <solar () openwall com>]

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