
On exploiting the jemalloc memory manager (2014) - jxub
http://phrack.com/issues/68/10.html#article
======
davidtgoldblatt
Another fun attack vector that I don't think has been well explored yet
involves the use of C++ sized deallocation functions. If a base class is
missing a virtual destructor, or if an array allocated with new[] is
deallocated with delete (instead of delete[]), then the allocation can be
freed with an incorrect size parameter. If this happens, you can trigger some
of the same sorts of state corruption issues that a double-free would cause
(you set a random bitmap bit to "free" in the metadata, since you're
calculating offsets from the start of a slab incorrectly).

Valgrind won't ever catch this, and Address Sanitizer won't always (it depends
on both the exact type of bug, and the sanitization settings).

~~~
chrisrohlf
When in doubt just assume Mark Dowd found it first
[http://taossa.com/index.php/2007/01/03/attacking-delete-
and-...](http://taossa.com/index.php/2007/01/03/attacking-delete-and-delete-
in-c) (dead link) but see here too [http://www.blackhat.com/presentations/bh-
usa-07/Dowd_McDonal...](http://www.blackhat.com/presentations/bh-
usa-07/Dowd_McDonald_and_Mehta/Whitepaper/bh-
usa-07-dowd_mcdonald_and_mehta.pdf)

~~~
davidtgoldblatt
Oh yes; while certainly mismatched new[]/delete has been a source of problems
since forever, what I mean specifically is the new types of exploits possible
with the "operator delete(void* ptr, size_t sz)" overload (and its array
cousin).

Before C++14, using delete (rather than delete[]) to deallocate an array of
ints (or other trivially destructible data types) would be safe in practice,
even though it was disallowed. In a world with sized deallocation functions,
it's exploitable.

