Learn, hack!

URL

http://ftp.ccc.de/congress/28C3/mp3-audio-only/28c3-4660-en-post_memory_corruption_memory_analysis.mp3

File name

28c3-4660-en-post_memory_corruption_memory_analysis.mp3

File size

28.5 MB

MD5

ee98a1dd27d4dc536441b433fc954011

SHA1

0ceec3d31d38231cb6b23af1bf2b42dddd573275

Pmcma is a tool aimed at automating the most time consuming taskes of exploitation. It for instance determine why an application is triggering a segmentention fault, evaluate if the faulting instruction can be used to write to memory or execute arbitrary code, and list all the function pointers potentially called from a given point in time by an application. Pmcma is a totally new kind of debugger, which allows for easy experimentation with a process in memory by forcing it to fork. The exact replicas of the process created in memory can then be intrumented while keeping the properties (eg: state of variables, ASLR, permissions...) of the original process. Pmcma is an easily extensible framework available under the Apache 2.0 license from http://www.pmcma.org/ . In this presentation, we introduce a new exploitation methodology of invalid memory reads and writes, based on dataflow analysis after a memory corruption bug has occured inside a running process. We will expose a methodology which shall help writting a reliable exploit out of a PoC triggering an invalid memory write, in presence of security defense mechanisme such as compiler enchancements (full RELRO, SSP...), or kernel anti exploitation features (ASLR, NX...). We will demonstrate how to:find all the function pointers inside a running process, how to determine which ones would have been dereferenced after the crash, which ones are truncable (in particular with 0x00000000). In case all of the above fail, how to test for specific locations overwrites in order to indirectly trigger a second vulnerability allowing greater control and eventually control flow hijacking. All of the above without source code, indeed ;) In the case of invalid memory reads, we will exemplify how indirectly influence the control flow of execution by reading arbitary values, how to trace all the unaligned memory access and how to test if an invalid read can be turned into an invalid write or used to infere the mapping of the binary. We will also introduce a new debugging technique which allows for very effective testing of all of the above by forcing the debugged process to fork(). Automatically. And with a rating of the best read/write location based on probabilities of mapping addresses (because of ASLR). Finally, since overwriting function pointers doesn't allow direct shellcode execution because of W^X mappings, we introduce a new exploitation technique which works even in the most hardcore kernels such as grsecurity. IT is called "stack desynchronization" and allows frame faking inside the stack itself. Those techniques are implemented in the form of a proof of concept tool available under the Apache 2.0 license at : http://www.pmcma.org/ .