https://support.apple.com/en-us/HT213906
I wonder though, wasn’t Blastdoor supposed to stop these privilege escalations in their tracks?
Some possibilities for how exploit could bypass protections of the blastdoor sandbox:
- The vulnerability was in an image decoding library that blastdoor calls, but which runs outside the sandbox. CoreGraphics frameworks are likely not sandboxed themselves. So memory corruption there could still lead to privilege escalation.
* The CoreGraphics frameworks like CGImage are core system libraries that predate Apple's sandboxing technologies. They were likely not designed with sandboxing in mind.
* These graphics libraries need to be able to access hardware acceleration features like OpenGL/Metal, read and write image files, and render to the screen. Sandboxing them would likely break many of those features.
* Apple may have determined that completely sandboxing mature system frameworks like CoreGraphics would impose too much performance overhead across the OS.
* As a result, for backwards compatibility and performance reasons, Apple seems to have exempted these core graphics libraries from being sandboxed processes.
- Payload encryption and upload to iCloud bypasses blastdoor. So compromise of an external service could have allowed running outside the sandbox.
Would love to see it run myself.
This sounds like chicken - egg scenario. Can you clarify how original shellcode bypasses those protections?
I don’t think you can disable DEP on runtime.
That being said, Apple implements a ton of mitigations, both on a hardware level and on a software level which generally makes exploits on Apple devices interesting to analyze and see how they bypassed stuff.
When exploiting a running system, your goal typically won't be to disable ASLR (which would only impact newly spawned processes), but instead to 'infoleak' where ASLR has placed important things you care about, so you know where to access them.
Modern devices have mechanisms like KPP/KTRR, though, which make it impossible to modify kernel code anyhow.
You also propose that CoreGraphics might not be sandboxed. CoreGraphics is a dynamic library which can be loaded into any process. It's _processes_ that are sandboxed, not dynamic libraries, so CoreGraphics can definitely exist in a process that has a sandbox profile applied just fine.
You also mention that graphics functions might not be sandboxed because they need to access graphics acceleration features. This is a good thought! In fact, the kernel extension that enables hardware graphics acceleration, IOMobileFramebuffer, is accessible from the app sandbox for this very reason. As a point of interest, many vulnerabilities have been discovered in IOMobileFramebuffer over the years -- it's an attractive target specifically because it's reachable from the app sandbox.
Lastly, you mention jailbreaking the sandbox. I know what you mean, but "jailbreaking" typically refers to a series of abilities, such as the ability to control the kernel task, the ability to create RWX pages, the ability to bypass the FreeBSD MAC policies, etc. The ability to bypass sandbox restrictions is only one condition of a jailbreak, and a sandbox escape doesn't imply a full jailbreak. Also, jailbreaking doesn't entirely break "the sandbox" -- it's a selective change that can be applied on a per-process basis.
Surprisingly, the decoding process had an extra step that did decoding out of the sandbox not so long ago, hopefully it's fixed now.
https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
Quite the opposite, but I think we need a better strategy. Downvoting a single offending comment is giving the spammer precise feedback on what worked and what didn't. Bot accounts should just be banned.
What a blunder.
In the note they state that the exploit was in image processing with PassKit and iMessage. Your comment somehow reads like an extrapolation what might have happened without any more actual knowledge that you share.
When rendering a PassKit image attachment, the iMessage app would call CGImageCreateWithJPEGData or CGImageCreateWithPNGData to decode the attached image file. However, the decoders likely did not properly bounds check the dimensions specified in the image header.
By crafting a malicious JPEG/PNG that specified inflated dimensions, an attacker could cause the decoders to allocate an overly large buffer to hold the decoded pixel data. When copying pixel data from the file into the buffer, the attacker could overflow the bounds of the buffer and overwrite adjacent memory.
The PassKit image preview process likely ran with elevated system privileges intended for rendering app content seamlessly. So the overflow could allow overwriting pointers stored in adjacent memory. By overwriting a function pointer, the attacker could divert code execution to their own shellcode embedded in the image file.
The shellcode would then disable memory protections like ASLR and DEP that normally prevent arbitrary code execution. This would allow the attacker to execute a ROP gadget chain or other payload to jailbreak the sandbox and run remote commands on the device.