[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-... (dead link) but see here too http://www.blackhat.com/presentations/bh-usa-07/Dowd_McDonal...

[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.

[mattbreeden]

https://web.archive.org/web/20070206052102/http://taossa.com...

First archive of the dead link