Further hardening glibc malloc() against single byte overflows(scarybeastsecurity.blogspot.com) |
Further hardening glibc malloc() against single byte overflows(scarybeastsecurity.blogspot.com) |
Is the LSB of the heap chunk size always >= 8?
What about a malloc_chunk->size with a multiple of 256? (Or anything else with an LSB < 7). With a one byte overflow one of this they could cause it to think that the size is up to 7 bytes more than the size of the real chunk.
The lower bits of ->size are actually masked off when considering a chunk's size, because they are flags:
#define SIZE_BITS (PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
/* Get size, ignoring use bits */ #define chunksize(p) ((p)->size & ~(SIZE_BITS))
So you really can't increase the size by less than 8. However, I know what you're now thinking: an attacker with a 1-byte overflow can mess with the flags! That would be a topic for another blog post, but I'm not aware of any techniques where messing with the flags would permit a clean ASLR bypass.
From: https://sploitfun.wordpress.com/2015/02/10/understanding-gli...
Last 3 bits of this field contains flag information.
PREV_INUSE (P) – This bit is set when previous chunk is allocated.
IS_MMAPPED (M) – This bit is set when chunk is mmap’d.
NON_MAIN_ARENA (N) – This bit is set when this chunk belongs to a thread arena.
You'd also incur substantial space overhead for small allocations in many cases. I'm not familiar with Linux's implementation, but on the Mac, for example, all allocations are a multiple of 16 bytes. It's common to allocate 16 or 32 bytes for small objects, so padding the allocation by one byte will bump you up to 32 and 48 bytes respectively.
Also Rust isn't the only option to write more secure code, it was already possible before C was even created using Algol and PL/I variants.
Quote from Tony Hoare's ACM award article in 1981, regarding Algol use in the industry, a programming language almost 10 years older than C.
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
EDIT: younger => older
Granted, if you link/call in code that uses ptmalloc (glibc's malloc) in Rust it is still an issue but unsafe code in Rust itself won't be vulnerable to this sort of attack.
Pascal, ADA, LISP, ATS, Java, Go, D, pony and all of the lisp and functional languages are safe.
Care to expand on that? I'm curious.
I imagine you missed the BBS and USENET flamewars against C.
No, bashing C is a common practice from those of us on the memory safe side of the fence since the early days.
Take the paper "A History of CLU"[0] describing how CLU was designed and implemented in 1975.
"I believe this is a better approach than providing a generally unsafe language like C, or a language with unsafe features, like Mesa [Mitchell, 1978], since it discourages programmers from using the unsafe features casually."
There are tons of other examples, all available in old papers, BBS and USENET archives.
[0] http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-56...
Which 80's startups like Sun and SGI used as basis for their workstation OSes.
Bjarne created C++, because after having to use BCPL instead of Simula to finish his PhD, he never wanted to work like that ever again.
So C with Classes started as a tool for Bjarne to target C, while staying productive and able to write safer code.