[HN Gopher] CVE-2024-54471: Leaking Passwords (and More!) on macOS
___________________________________________________________________
CVE-2024-54471: Leaking Passwords (and More!) on macOS
Author : nmgycombinator
Score : 227 points
Date : 2025-03-20 16:47 UTC (6 hours ago)
(HTM) web link (wts.dev)
(TXT) w3m dump (wts.dev)
| janandonly wrote:
| A very interesting article this is. Never knew there was so much
| lore in the making of the Mach and Darwin kernels .
| nmgycombinator wrote:
| 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.
| junon wrote:
| 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.
| diggan wrote:
| > 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
| nmgycombinator wrote:
| > 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 wrote:
| 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.
| nmgycombinator wrote:
| 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)
| technothrasher wrote:
| > "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.
| nmgycombinator wrote:
| 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 wrote:
| >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
| nmgycombinator wrote:
| > I understand the technical reasons for that, but it is
| technically supported by the spec and other clients work
| with it just fine.
|
| I am completely aware of that, but I am aware that other
| clients handle it just fine. The bug actually forced me
| to use a different client for when I actually _needed_ an
| FTP client.
| saghm wrote:
| > 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...
| esdf wrote:
| And more!
|
| https://bugzilla.gnome.org/show_bug.cgi?id=758032
|
| https://github.com/linuxmint/cinnamon-
| screensaver/issues/354
| nickdothutton wrote:
| Thanks for reminding me about XDM a source of seemingly
| infinite vulnerabilities.
| dogma1138 wrote:
| Freakazoid moment...
| kps wrote:
| > ... 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...)
| pixl97 wrote:
| 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.
| SoftTalker wrote:
| 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 wrote:
| Take a look at it yourself if you're curious. The kernel
| code is open source: https://github.com/apple-oss-
| distributions/xnu
| jonathanstrange wrote:
| 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 wrote:
| Damn, that's honestly hilarious.
| oneplane wrote:
| 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.
| nmgycombinator wrote:
| > manually unlocked a local Keychain
|
| Does the Keychain stay unlocked for a while? And do
| people actually do this?
| oneplane wrote:
| Yeah so it really depends on the local setup. Here's a
| wall of text if you're interested:
|
| Say you do software development with a platform
| engineering and cloud flavour on top, you might be using
| aws-vault to keep access keys and SSO session keys in a
| dedicated keychain rather than in plaintext in ~/.aws/.
| That keychain has an ACL that only allows aws-vault to
| access it, and has a self-lock timeout of a few minutes.
| This is great, because it is pretty secure, there is
| nothing to 'steal' (even from an unlocked machine) and
| it's still extremely convenient.
|
| However. Say you do this with an external non-TouchID
| keyboard, when the STS timeout expires and you need to
| re-authenticate, you also need to unlock the keychain for
| a few seconds so aws-vault can either read out the SSO
| session tokens or the static secret for non-SSO usage,
| and it has to write back the new STS session.
|
| During that window, the keychain unlock from such a
| keyboard means manual password entry, which in turn means
| that has to be in memory for a bit. Because a legacy
| keychain doesn't use data protection (but if you create a
| new one you do have that option) it's essentially just an
| AES encrypted file on disk. Because humans aren't likely
| to remember an AES key, it's derived and wrapped so you
| have some KDF that uses a user-selected password, which
| has to be in memory for a bit while the key is
| unwrapped/derived. The AES key itself has to stay in
| memory the entire duration of the unlocked state of the
| keychain, because without the AES key it can't read or
| write secrets.
|
| Technically, the same happens to encrypted disk images
| (the AES ones at least, other types I'm not 100% sure).
| The DEK has to stay in memory while it is in use. It's
| why Apple started using systems like cryptexes and SSVs
| so the container disk is almost irrelevant from an
| integrity point of view. Before that, encrypted disks
| were an all-or-nothing approach.
| nmgycombinator wrote:
| Oh fascinating. And it seems I had my terms confused. I
| didn't know the items themselves were called keychains.
| TylerE wrote:
| I mean, you should really just assume that physical access =
| owned.
| nmgycombinator wrote:
| > grep any user's FileVault password from the page file
|
| I'm not sure if this necessitates physical access.
| gruez wrote:
| A filevault password is useless unless you have
| root/physical access. If it's mounted by the system, then
| filesystem ACLs will still be in effect. Otherwise you
| need root to read raw block devices.
| seppler wrote:
| I also submitted a report for CVE-2011-3226 for a password-less
| login, referenced here: https://support.apple.com/en-us/103345
| turnsout wrote:
| 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?
| oneplane wrote:
| 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.
| nmgycombinator wrote:
| 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._
| biofunsf wrote:
| 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 wrote:
| 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 wrote:
| 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.
| nixpulvis wrote:
| "ACLs don't":
| https://waterken.sourceforge.net/aclsdont/current.pdf
___________________________________________________________________
(page generated 2025-03-20 23:00 UTC)