Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

WebContent->EL1 LPE: OOBR in AppleCLCD / IOMobileFrameBuffer- 574

saaramarPosted 4 Years Ago
  • The author was reversing applications of accessible from the IOServices from the app sandbox. While reviewing the decompilation of the code, they found a fairly trivial bug (in theory) within AppleCLCD/IOMFB.
  • The bug is an arbitrary write with a controlled 32-bit integer index for accessing an IOSurface object. There is no validation on the value of the index being accessed! How can this flow be triggered? The entitlement com.apple.private.allow-explicit-graphics-priority is required. The app sandbox does not have this entitlement, but WebKit.WebContent does.
  • The POC is super simple for this! Obtain a userclient to AppleCLCD/IOMobileFramBuffer and call IOConnectCallMethod with selector=83, and set the scalar input to be a very large number. With the right entitlements this causes a kernel panic.
  • To exploit this, the author can either craft a fake IOSurface object or use an actual one. They choose to go with the latter because this primitive allows for the freeing of the object as well! This creates a UAF on the object in it's original space. The IOSurface represents a userspace buffer that is shared with the kernel.
  • This object is amazing for exploitation on iOS. This is because the object can easily be created and freed by specifying specific functions. Then it is perfect for spraying controlled data because of the s_set_value function. The author includes three links to using this struct for exploitation in iOS.
  • The first step is to get an information leak. By spraying an insane amount of IOSurface objects, the author found a usable offset of 0x1200000 bytes. Using Corellium EL1 debugging, the hosted/emulated iOS, made the debugging significantly easier for testing this as well.
  • The article ends with the bug being triggered, with the proper offset, to dereference a pointer being read that we control. As a result, this is quite an exploitable bug! The author stops at this point... They planned on posting a full r/w primitive but the bug was patched prior to them getting to the point. Overall, I really enjoyed the description of the bug and the explanations from the author though!