Root Persistence via macOS Recovery Mode Safari | Hacker News Reader

Root Persistence via macOS Recovery Mode Safari

yaseenghanem.com

26 pointsyaseeng17 comments

For context: I submitted this to Apple in September 2025 and waited 6 months before publishing. Apple closed both reports citing FileVault as a mitigation, which is technically accurate but FileVault is opt-in and many people disable it during setup without understanding what it does (myself included when I got my MacBook in 2020). My personal view is that the behavior significantly reduces the effort required to persist data on an unencrypted system compared to for example side-loading Linux. Regardless, Tahoe 26.3 (It might have been patched before, I didn't check) appears to have silently patched both issues.

> which is technically accurate but FileVault is opt-in

It's been on by default since around circa 2013.

Also, Filevault is on top of the encryption provided by secure enclave

> many people disable it during setup without understanding what it does

Citation required. Most people don't disable things on their computer when they "don't understand what it does."

> myself included when I got my MacBook in 2020

That's an anecdote, not evidence of a trend in a population.

> Tahoe 26.3 (It might have been patched before, I didn't check) appears to have silently patched both issues.

Gotta love a clickbait title designed to make people panic....about a minor fixed two months ago

> It's been on by default since around circa 2013

Wrong. It's not on by default.

https://apple.stackexchange.com/questions/324805/do-apple-la...

You boot an operating system on the machine, you have access to all unencrypted files, what is so strange about this ? You can do the same thing with Terminal. And smells of GenAI...

EDIT: The person I replied to entirely rewrote their comment (with no indication they did so) so mine seems weird now, apologies for that.

Apple fixed the issue it seems, but did kind-of-sort-of ignore it. The argument from the OP is that it requires physical access, you don't need to convince the user to do anything, the attacker can do it...

...which Apple pointed out (in the article you're commenting on) that if FileVault was enabled this wouldn't be possible, which is true.

And if you have physical access and no encryption, then it's kind of game over anyway. But still, kind of neat to find something like this and Apple fixed it regardless

Yep. While the Terminal is not an option from the 4 apps listed in the initial screen, it's available from Utilities → Terminal at the top. They even provide a convenient way to access the hard drive from another computer: https://support.apple.com/guide/mac-help/macos-recovery-a-ma...

You're right that Terminal is accessible via Utilities, but Target Disk Mode and Terminal both require an admin password. Safari bypassed that authentication entirely, writing directly to protected system locations with no admin password

> Terminal both require an admin password

Not in my testing.

Apple tries to lock down access at the very least. They also patched the vulnerability twice (they restricted Safari for some reason and they also disabled the settings in the new version of Safari). It seems like Apple cares at the very least. Which is weird, because they also give you a terminal?

Lots of people I've met were surprised that I was able to get their photos from their windows laptops without ever needing their password. Especially these days in the age where even phones and Windows 11 will enable encryption by default, it's a tad weird that disk encryption isn't on by default on macOS. I, at the very least, was surprised that disk encryption isn't mandatory and always on on macOS, seeing the way Apple controls both the OS and the TPM firmware so that they're pretty much immune to the dreaded "BIOS update made my laptop ask for bitlocker" problem you get on Windows.

I don't really get why this would be AI generated, what makes you think that?

At the very least the author's submission and follow-ups to Product Security looks written by AI.

I come from an Arabic-speaking household so my English can be a bit funky sometimes, sorry. However I did use Claude to help format the CVSS tables and polish the grammar in the formal Apple submission (I was 17 submitting to a major company's security team for the first time). The research and findings however are entirely original.

This isn't "research", kid.

Completely agree on the encryption point. Apple controls the entire stack and could mandate FileVault encryption by default. The fact that it's opt-in is a weird decision that hasn't caught up with their security posture elsewhere.

On the Terminal point, its worth clarifying that Recovery Terminal does require mounting the data volume first, which typically prompts for an admin password. Safari bypassed that step entirely, which is what made it interesting.

Interesting point on the missing admin password, that does pose a slightly higher risk.

Though IIRC, at least the Intel Macbooks still support some kind of Target Disk Mode that should also bypass the admin password? I don't know if that requires an admin password but none of the guides I can find online state that it's required.

Actually this is a distinction worth clarifying, in Recovery Mode, Terminal does require mounting the data volume first, which typically prompts for an admin password. Safari bypassed this entirely, writing directly to protected system locations without any authentication. Furthermore, no GenAI was used in writing the article I come from an Egyptian Speaking background so my English may be a bit funky, sorry :)

> in Recovery Mode, Terminal does require mounting the data volume first, which typically prompts for an admin password.

This is not my experience. The Data volume mounts automatically, and there's no password prompt.

I concur, that is the normal behavior without FDE. But besides, you can still use the Terminal of _any_ other bootable OS X disk, not just the recovery itself. With FDE, neither of this will work.

Reply on news.ycombinator.com