Very curious about the exploitation of CVE-2025-24252, a use-after-free (UAF) using which they achieved zero-click RCE on MacOS. This is inspite of ASLR and heap exploitation mitigations in place to mitigate such vulnerability classes
On ASLR: you might use the UAF to access memory regions you shouldn’t have access to. By reading the contents, they can potentially leak pointers to a critical library (e.g., libc), allowing them to calculate the offsets to bypass ASLR.
On heap protection: if you spray the heap with predictable data patterns you can improve your chance of landing a useful address, even with ASLR in place
CVE-2025-24252 and CVE-2025-24132 are two examples. Doing a search for "Oligo" in release notes gives various other results, e.g.,
* https://support.apple.com/en-ca/122374
Apple fixed their stuff, but third-parties who used their SDK will have to issue updates as well.
Very curious about the exploitation of CVE-2025-24252, a use-after-free (UAF) using which they achieved zero-click RCE on MacOS. This is inspite of ASLR and heap exploitation mitigations in place to mitigate such vulnerability classes
https://security.apple.com/blog/towards-the-next-generation-...
On ASLR: you might use the UAF to access memory regions you shouldn’t have access to. By reading the contents, they can potentially leak pointers to a critical library (e.g., libc), allowing them to calculate the offsets to bypass ASLR.
On heap protection: if you spray the heap with predictable data patterns you can improve your chance of landing a useful address, even with ASLR in place
[dead]
Good thing I'm still on macOS 12