Running a parser for a network protocol as root seems like a pretty unnecessarily dumb thing to do. I can't really imagine why any part of airplay would need to run as root; maybe something to do with DRM? Although the DRM daemon `fairplayd` runs as a limited-privilege user `_fpsd`, so maybe not. So bizarre that Apple makes all these cool systems to sandbox code, and creates dozens of privilege-separated users on macOS, and then runs an HTTP server doing plists parsing as an unsandboxed root process.
Mindwipe · 67d ago
Apple have reworked Airplay so many times at this point the entire thing is just a massive pile of technical debt piled on another massive pile of technical debt, piled on a bunch of weird hacks to try and keep all the devices built for previous versions afloat.
walterbell · 67d ago
At least it can be disabled via MDM/Configurator policy.
bigyabai · 67d ago
To the express benefit of all 3 Apple users that configure their devices with a PList editor.
walterbell · 67d ago
The breaches will continue until device policy improves.
bigyabai · 67d ago
Three cheers for smart defaults!
throw0101a · 68d ago
CVE-2025-24252 and CVE-2025-24132 are two examples. Doing a search for "Oligo" in release notes gives various other results, e.g.,
Apple fixed their stuff, but third-parties who used their SDK will have to issue updates as well.
john_alan · 67d ago
Heya, is it possible to detect the worm on iOS / macOS?
Does the fix in latest OS just remove the worm if unknowingly infected?
Reads like a zero click infection leading to arbitrary execution of long running code.
Seems fairly insidious?
paulddraper · 67d ago
Zero-click local network RCE on macOS: 102 points
Article titled "Someone At YouTube Needs Glasses" about YouTube layout: 837 points and rising
Hacker News my a*s
m463 · 67d ago
macos is pretty promiscuous, and I've noticed random airplay displays (like the neighbors) showing up in the mirroring dropdown in the dock.
wonder if this is a way to get into the stack.
greyadept · 67d ago
This behaviour always made me feel a bit suspicious about airplay but I reassured myself that Apple surely had it locked down. But these 17 CVEs show that my trust was misplaced.
abhisek · 68d ago
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
RainyDayTmrw · 67d ago
I understand heap sprays in theory. In practice, how do they avoid clobbering something important and crashing the app? It seems like a typical app has a lot of state to clobber.
xyzzy123 · 63d ago
The writes for a spray are pre exploit, you are going through an allocator to get the space you're writing to. Put another way, its the apps job to write the spray into "free space".
Sprays are pretty crashy but the heap setup is not usually the problem, its that the pointer you want to control "missed" the sprayed area.
RainyDayTmrw · 67d ago
Oof. It's parsing and memory corruption again.
pjmlp · 67d ago
Basically a collection of use-after-free, stack-based buffer overflow, type confusion, memory exhaustion, integer overflow, NULL pointer dereference, for the most part.
However we all know that the problem is that juniors and interns are the ones that get to write this code, a senior with proper education would never deliver these mistakes into production. /s
hoseja · 61d ago
Thankfully, the borrow checker will protect you from delivering anything at all.
rubatuga · 68d ago
Good thing I'm still on macOS 12
slama · 68d ago
macOS 12 is EOL and is no longer receiving security updates.
There’s a strong chance it’s vulnerable, too
waterTanuki · 66d ago
The most important question remains unanswered: would Rust have prevented this?
* 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.
Reads like a zero click infection leading to arbitrary execution of long running code.
Seems fairly insidious?
Article titled "Someone At YouTube Needs Glasses" about YouTube layout: 837 points and rising
Hacker News my a*s
wonder if this is a way to get into the stack.
https://security.apple.com/blog/towards-the-next-generation-...
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
Sprays are pretty crashy but the heap setup is not usually the problem, its that the pointer you want to control "missed" the sprayed area.
However we all know that the problem is that juniors and interns are the ones that get to write this code, a senior with proper education would never deliver these mistakes into production. /s
There’s a strong chance it’s vulnerable, too