Leaking Passwords and more on macOS
56 comments
·March 20, 2025junon
technothrasher
> "empty password tried twice" root login bypass
Sounds like the time my cat hacked my Sun 3/60 by simply sitting on the keyboard. XDM crashed when the username buffer hit 256 random characters, and then dropped a root shell. But this was in the early 90's when everybody was a lot more innocent about security.
nine_k
Back in the day, on my first day in a huge corporation famous for its refined engineering culture, I was issued a laptop that had some installation program running, to create a user for me, enroll on the corp network, etc. It had a bug, which made it run certain actions in an infinite loop.
I pressed Ctrl+C, and got a root shell. From it, I ran the enrollment scripts I could find; it gave me sufficient access to pull from the corporate repo. So I took a ticket, found a related bug in the code, and created a patch fixing it on the first day, technically by cracking into a corporate laptop. (I had to wait for a properly completed enrollment to be able to push the code.)
nmgycombinator
I feel like that (innocence about security) might be a bit of the reason why this vulnerability existed in the first place. I'm sure the NetAuthAgent code is very old, and was probably written at a time before even Apple was serious about security. And what really can you add new to a web server client? I wouldn't be surprised if the entitlement check is the first thing they've added to it in years.
It's funny, Apple themselves even suggest people use other apps for FTP: https://support.apple.com/guide/mac-help/servers-shared-comp...
> With read-only access, you can copy files from the server, but to copy files to the server, you may need another FTP app. Choose Apple menu > App Store to find FTP apps available for macOS.
Another funny note: NetAuthAgent has had a bug for years where you cannot connect to an FTP server if your username contains an `@` symbol. I understand the technical reasons for that, but it is technically supported by the spec and other clients work with it just fine. I'd dig up some old posts talking about it going back years, but I don't want to put in the effort, lol.
retox
>NetAuthAgent has had a bug for years where you cannot connect to an FTP server if your username contains an `@` symbol.
Basic auth and FTP had a username password schema like
ftp://username@ftpserver.address.com and even
ftp://username:password@ftpserver.address.com
kps
> … hacked my Sun 3/60
L1-A to bring up the boot monitor. Search memory for `/bin/login` and replace with `bin/ed`. Enter any file name as your ‘user’ name, or just junk, and use `!sh`.
(Amazing what you remember from school…)
jeffs4271
Glad to see vax and 68k sun guys of my vintage here still. The security game was different then. Miss the simple life. :-)
saghm
> But this was in the early 90's when everybody was a lot more innocent about security.
There are definitely more recent flaws that might have been suspectible to "cat butt on keyboard", like this one in 2016: https://www.bleepingcomputer.com/news/security/linux-flaw-al...
dhosek
I remember the first time I encountered a Windows machine you had to log in to to use (1996). At my first job, I had write access to all the system directories on the corporate VAX machine. I could have easily taken down a major corporation through a careless mistake (but fortunately, never did).
SoftTalker
MacOS is descended from NeXTSTEP which dates back to the 1980s. There is probably a lot of terrible code in there.
Edit: terrible from today's security perspective, I meant.
nmgycombinator
Take a look at it yourself if you're curious. The kernel code is open source: https://github.com/apple-oss-distributions/xnu
pixl97
I remember using Novell netware in high school and if you random long lengths of passwords you could get the machine to crash. Didn't have any idea what was going on at the time.
After highschool I saw an exploit for this where if you typed the right magic characters in you could highjack the execution of the login prompt and get a shell.
spullara
back in the 80s I got into a DEC system by doing roughly the same thing to an application running on VMS. basically you when it interrogated the terminal you could overflow it and drop into the command line.
diggan
> It reminds me of the zero day that Apple tried to cover up somewhat - the "empty password tried twice" root login bypass. This was ca. 2017 or so, maybe 2018.
2017 it seems, submission at the time: "macOS High Sierra: Anyone can login as “root” with empty password" - 3001 points | 1073 comments - https://news.ycombinator.com/item?id=15800676
hunter2_
Aside: >1000 comments in 2017 is significant. Is there a straightforward way to list such highly-engaged HN submissions? Ideally sorted by prominence within a short (1yr is fine) time window, but a simpler sort (no regard for prominence, just absolute engagement, which would strongly tilt the results toward the present, due to platform growth) would also be ok.
nmgycombinator
> Interesting to see the port system mentioned - it's not a well known fact of Mach kernels.
I'm surprised to hear someone say that, given that it's the fact about Mach to me. I'm not sure how people could know about Mach but not its defining system.
kccqzy
Maybe OP is referring to the fact that there is a Mach kernel underneath. Most developers I guess would like to write CLI apps that are portable to Linux and macOS, so they only use the POSIX side of the API. These don't need to know about ports. And if developers are writing Mac-specific software, Core Foundation is probably the lowest practical level they will go with.
junon
Yes, that's what I meant. I'm making a kernel that uses ports not dissimilar to Mach's and I get asked if there are other modern kernels that do the same thing from time to time. Everyone I've talked to has been surprised to hear it has them.
nmgycombinator
Yeah, if you're writing user-facing apps, writing against Mach wouldn't be smart. But if you're a vulnerability researcher on the other hand... it's a neat trick and might just help you find a CVE! (even though most stuff has moved to XPC now and you could just used the public XPC API's there)
seppler
I also submitted a report for CVE-2011-3226 for a password-less login, referenced here: https://support.apple.com/en-us/103345
jonathanstrange
That's nothing. You used to be able to grep any user's FileVault password from the page file for many years. It was a simple one-liner and worked 100% of the time.
nmgycombinator
Damn, that's honestly hilarious.
oneplane
TBH this is still possible in some scenarios, mostly when someone isn't using data protection and manually unlocked a local Keychain. It's pretty much the same as dumping LSASS memory on Windows when IOMMU isn't used, and in some cases even when IOMMU is used.
TylerE
I mean, you should really just assume that physical access = owned.
nmgycombinator
> grep any user's FileVault password from the page file
I'm not sure if this necessitates physical access.
nixpulvis
"ACLs don't": https://waterken.sourceforge.net/aclsdont/current.pdf
nmgycombinator
Great article! Thanks for the link!
nmgycombinator
A minor correction was made to the article:
Entitlement checks are not in the Mach layer of the kernel.
https://github.com/nmggithub/wts/commit/2bdce1c0c76c7adc360e...
Just a one word change, fixing a factual inaccuracy when talking about how XNU works.
corank
> if a process were to expose a mechanism for other processes to essentially proxy keychain queries through it, that can undermine the security of the whole system.
This looks like a case of confused deputy problem: https://en.wikipedia.org/wiki/Confused_deputy_problem
A capability-based design should be able to systematically prevent this kind of problems.
biofunsf
Does the author provide the actual PoC code anywhere? I want to do some testing for mitigations. I see the example code but it seems incomplete.
Realistically what are the risks?
nmgycombinator
The PoC code should work. You just need to install Kass as a dependency. If you have done that, are there any other issues you are facing?
As far as risks are concerned: any app with the ability to get a send right to NetAuthAgent (pretty much any un-sandboxed app) can just silently as NetAuthAgent for any saved credentials for file drives (FTP, WebDAV, Samba, etc.), as well as chaining into a leak of all iCloud Contacts and Calendars (plus other stuff from iCloud). Sandboxing makes it difficult, but not impossible.
The risks are zero if you're up to date (and the patch was in October of last year, so you honestly should be up to date already). If you are not up to date for whatever reason and choose not to be, the risks are far more (unless you diligently check every single process that ever runs on your device).
nmgycombinator
Well, it took 8 hours, but this post is now no longer top 5 on the front page (it's #27 now for me, so still front page, just the bottom). Thank you everyone for your comments!
janandonly
A very interesting article this is. Never knew there was so much lore in the making of the Mach and Darwin kernels .
nmgycombinator
Oh there's quite a lot of lore. Mach goes back even further to even earlier CMU kernel called Accent: https://en.wikipedia.org/wiki/Accent_kernel.
turnsout
At this point it feels like Mach is a reliable source of bugs in macOS. I know Apple is working hard to lock it all down, but is there any path to shifting away from Mach completely?
nmgycombinator
I would argue that Mach was not the source of the bug here, but rather it was the lack of an entitlement check. Entitlements are honestly a very good security system, but they are opt-in. If a daemon doesn't check entitlements, then its insecure. Don't blame the messaging mechanism, blame the way it is used.
To be honest, any sort of locked down messaging system requires more (i.e. validation of sender, etc.) than just the transfer of messages. And that's just not something you would get with a low-level communication protocol like Mach (unless Apple overhauled the MIG compiler to add entitlement checks).
Mach is fantastic when paired with entitlement checks.
oneplane
Yes, there was a post recently about moving more and more parts out of Mach. Some of it to L4, some of it to user space.
Technically, this might actually increase the potential attack surface (due to more different components existing together). But more specialised surface would then allow for simplified control and as an effect better protection of that surface.
unit149
[dead]
Well written article. It reminds me of the zero day that Apple tried to cover up somewhat - the "empty password tried twice" root login bypass. This was ca. 2017 or so, maybe 2018.
You were able to type in an administrator username in any root sign in box (e.g. in the settings panel via the padlock icon) with an empty password. Hitting the Sign In button the first time told you that the password was incorrect. Dismissing that alert box and hitting sign in a second time signed you in as that user.
We were able to reproduce it 100% of the time day-of, and of course was patched pretty shortly after making the rounds on social media. Still seems like a massive oversight though.
Seems there's still some cruft around the auth mechanisms in Mac. Interesting to see the port system mentioned - it's not a well known fact of Mach kernels.