Re: memory allocator upstream patches

[Jan Lieskovsky <jlieskov () redhat com>]

Hello Xi, Kurt,

  thank you for your report and notification.

It doesn't look that the issues below have got CVE identifiers
assigned yet. Thus assuming your report was also a simultaneous
request for the identifiers, not just notification, correct?
Can you confirm that?

Kurt,

  once confirmed, could you please allocate CVE ids for these
flaws? (me not sure if the 'bionic' one case below being open-source,
but for the rest the request(s) look valid).

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

On 06/05/2012 07:54 AM, Xi Wang wrote:
> Hi,
>
> I would like to share some upstream patches of two specific types
> of memory allocator vulnerabilities.
>
> * malloc(n) size overflow.
>
> Consider the following code pattern.
>
>         n = read_from_input();
>         p = malloc(n);
>         if (p)
>                 memcpy(p, input_buffer, n);
>
> Some malloc() implementations internally perform alignment/padding
> for a large n, and the allocation size wraps around to a small
> integer.  That means they would allocate a smaller buffer than
> expected, leading to buffer overflow.
>
> * calloc(n, size) size overflow.
>
> Some calloc() implementations don't check for n * size multiplication
> overflow, and would allocate a smaller buffer than expected,
> leading to buffer overflow.
>
> The two types of vulnerabilities can be easily reproduced using
> malloc(-1) and calloc(BIG-VALUE, BIG-VALUE).  If the return values
> are non-null, the implementations are likely to be problematic.
>
> See a more complete list at:
>
> http://kqueue.org/blog/2012/03/05/memory-allocator-security-revisited/
>
> Below are some recent upstream fixes.
>
>
> Boehm-Demers-Weiser GC (libgc)
> ==============================
>
> malloc() size overflow, upstream patch (revised by the developers):
>
> https://github.com/ivmai/bdwgc/commit/be9df82919960214ee4b9d3313523bff44fd99e1
>
> The bug in mallocx.c was found by Ivan Maidanski.
>
> calloc() size overflow, upstream patch (revised by the developers):
>
> https://github.com/ivmai/bdwgc/commit/e10c1eb9908c2774c16b3148b30d2f3823d66a9a
> https://github.com/ivmai/bdwgc/commit/6a93f8e5bcad22137f41b6c60a1c7384baaec2b3
> https://github.com/ivmai/bdwgc/commit/83231d0ab5ed60015797c3d1ad9056295ac3b2bb
>
>
> bionic (Android libc)
> =====================
>
> malloc() size overflow, upstream patch (revised by the developers):
>
> https://github.com/android/platform_bionic/commit/7f5aa4f35e23fd37425b3a5041737cdf58f87385
>
> NB: this vulnerability could only be triggered in debug mode, the
> same as CVE-2009-0607, calloc() size overflow.
>
>
> nedmalloc
> =========
>
> malloc() size overflow, upstream patch:
>
> https://github.com/ned14/nedmalloc/commit/1a759756639ab7543b650a10c2d77a0ffc7a2000
>
> calloc() size overflow, upstream patch:
>
> https://github.com/ned14/nedmalloc/commit/2965eca30c408c13473c4146a9d47d547d288db1
>
>
> Hoard
> =====
>
> http://www.hoard.org/
>
> malloc() size overflow, confirmed by the developers via email in
> this March, no upstream patch available (since 3.8).
>
> calloc() size overflow, which should only happen on non-glibc
> platforms (e.g., Mac OS X).  It has not been confirmed by the
> developers, but one can easily reproduce it.
>
>
> boost::pool
> ===========
>
> ordered_malloc() (similar to calloc()) size overflow, upstream patch:
>
> https://svn.boost.org/trac/boost/changeset/78326
>
>
> - xi