Difference between revisions of "HFS Heap Overflow"

From The iPhone Wiki
Jump to: navigation, search
(initial page)
 
(References)
Line 11: Line 11:
 
==References==
 
==References==
 
*[http://pod2g-ios.blogspot.com/2012/01/details-on-corona.html pod2g's blog]
 
*[http://pod2g-ios.blogspot.com/2012/01/details-on-corona.html pod2g's blog]
  +
*[http://media.blackhat.com/bh-us-11/Esser/BH_US_11_Esser_Exploiting_The_iOS_Kernel_Slides.pdf i0n1c's Heap Feng Shui paper]
*ionic's Heap Feng Shui paper (can't find link right now)
 
 
*[https://www.corelan.be/index.php/2011/12/31/exploit-writing-tutorial-part-11-heap-spraying-demystified/ All about Heap Spraying]
 
*[https://www.corelan.be/index.php/2011/12/31/exploit-writing-tutorial-part-11-heap-spraying-demystified/ All about Heap Spraying]
   

Revision as of 08:08, 10 February 2012

By fuzzing the HFS btree parser, a heap overflow in the zone allocator was found. Mounting a clean, overflowed and payload images in a Heap Feng Shui way worked. The kernel heap overflow exploit copies 0x200 bytes from the vnimage.payload file to the kernel sysent, replacing a syscall to a write anywhere gadget. Some syscalls (first 0xA0 bytes and the last 6 bytes) are trashed in the operation because the HFS protocol needed to be respected. So these bytes are restored as fast as possible to get a stable exploit, then the write anywhere is used to copy the kernel exploit and jump to it. The kernel exploit just patches the kernel security features, as usual.

Credit

  • pod2g for finding the vulnerability and writing the exploit
  • i0n1c for his papers on Heap Feng Shui

References

Apple-logo.png This article is a "stub", an incomplete page. Please add more content to this article and remove this tag.