Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181210154020.GA2063@openwall.com>
Date: Mon, 10 Dec 2018 16:40:20 +0100
From: Solar Designer <solar@...nwall.com>
To: Pavel Cheremushkin <Pavel.Cheremushkin@...persky.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: 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

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.