Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 13 Dec 2018 11:39:29 +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 07:57:21PM +0100, Solar Designer wrote:
> https://github.com/LibVNC/libvncserver/issues/247
> 
> Upstream's fix appears to be to add casts to (uint64_t) before adding 1
> in those many malloc() calls.  On platforms with larger than 32-bit
> size_t, this should be sufficient against integer overflows since the
> sizes are read from 32-bit protocol fields, but it isn't sufficient to
> prevent maliciously large memory allocation on the client by a rogue
> server.  On a platform with 32-bit size_t, this isn't even sufficient to
> prevent the integer overflows.  If I haven't missed anything, it'd be
> great if you open a new issue suggesting introduction of safety limits
> prior to those malloc() lines.

> [...] per the commits referenced in issue #247 above, there are many more
> instances of the "malloc(... + 1)" pattern, which were patched similarly
> incompletely.

I've just created this issue:

SECURITY: malloc((uint64_t)length + 1) is unsafe, especially on 32-bit systems
https://github.com/LibVNC/libvncserver/issues/273

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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.