There are some misconceptions in your comments that I think could be useful to clear up.
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.
> 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.
Surprisingly, the decoding process had an extra step that did decoding out of the sandbox not so long ago, hopefully it's fixed now.
For a „best guess“ you’re making quite detailed assumptions, of which I have no idea and you bring up no reasons how you can assume these.
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.
> Do we want to encourage the use of LLMs in discussion?
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.
The bug is in the WebP decoder. Shellcode execution is not been a thing on iOS because of codesigning. ROP is basically not a thing on new devices because of PAC.
> 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.
This sounds like chicken - egg scenario. Can you clarify how original shellcode bypasses those protections?
DEP is a Windows implementation of a non-executable stack, i.e., memory permissions that do not allow execution on specific pages. Depending on the situation, an attacker can e.g., mmap() a new page with the execute permission set, write his shellcode there and jump there. Another way to bypass the NX bit is to actually use gadgets (snippets of code essentially) that are already there in the code thus they can be executed and redirect your instruction pointer to those addresses. Reusing code is generally known as ROP, JOP etc. and is mitigated by PAC for ARM (after v.8.3) and CFI for Intel (11th Gen onwards I believe).
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.
Edit: For clarity, Apple requires both codesigning and implements PAC, among others. mmap'ing or ROP won't make the cut in this case.
> 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.
This is such a trivial exploit, why in the world they decided to write an own JPEG decoder, and stumble on the seemingly most trivial case of input sanitation?
I would add sole reliance on sandboxing instead of principial stance on writing on overall secure, high quality, and higly verified codebase is obviously failing.
