<story><title>How a double-free bug in WhatsApp turns to remote code execution</title><url>https://awakened1712.github.io/hacking/hacking-whatsapp-gif-rce/</url></story><parent_chain><item><author>mgrviper</author><text>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.</text></item></parent_chain><comment><author>umanwizard</author><text>How 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?</text></comment>
<story><title>How a double-free bug in WhatsApp turns to remote code execution</title><url>https://awakened1712.github.io/hacking/hacking-whatsapp-gif-rce/</url></story><parent_chain><item><author>mgrviper</author><text>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.</text></item></parent_chain><comment><author>shaklee3</author><text>This 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.</text></comment>