3 ms·
At first i was wondering how one can get RCE out of double-free and then author proceed to drop a bomb - android would reliably return same adress to the next t
by mgrviper 7y ago
At first i was wondering how one can get RCE out of double-free and then author proceed to drop a bomb - android would reliably return same adress to the next two allocations of same size as freed memory. Android behaviour here is simply unacceptable. One would expect (yeah) memory managment bugs from user space applications, but return same memory from a default allocator twice because of double-free is a terrible peculiarity, undefined behavour or not.
- umanwizard 7y agoHow do other malloc implementations avoid this? It seems natural if what “free” does involves adding the pointer to some free list. Obviously you wouldn’t want to scan the whole free list every time looking for duplicates - is there another way to avoid this behavior?
- tedunangst 7y agoBitmaps don't require scanning.
- saagarjha 7y agoThey do, you'd just scanning a smaller thing.
- tedunangst 7y agoWhat are you scanning the bitmap looking for? Why not just index into it and look at the relevant bit?
- shaklee3 7y agoThis has happened to me in ubuntu 18.04 frequently. Do you have something showing that this is really that rare? If anything, it might help you track down bugs quicker.
- lubesGordi 7y agoYou say this is a peculiarity, but then don't say what it should do instead. Is there some other widely used implementation that doesn't do this? Like others say, scanning the free list for dupes seems inefficient.
- gpderetta 7y agoThe allocator in question runs in userspace.
- nothrabannosir 7y agoMalloc is a user space lib, not a syscall. The OS only deals in pages, on Linux accessed using brk and mmap.
- not2b 7y agoIf the user hasn't messed up (with a double free), re-using the same block if the next malloc/new requests the same size block is the most efficient approach; it will have better caching behavior than selecting a completely different block. So this behavior isn't surprising. It seems you are asking for the allocator to spend extra cycles and produce worse caching behavior as a defensive measure. It might be possible to cheaply check for this particular error condition (the double free is two consecutive free calls with no intervening malloc or free) but the exploit writer will be able to see the code and work around it. The right solution is to guarantee that your codec doesn't do a double free.