7 ms·

Leaking Passwords and more on macOS

325 points by nmgycombinator 2y ago

janandonly 2y ago
A very interesting article this is. Never knew there was so much lore in the making of the Mach and Darwin kernels .
- nmgycombinator 2y ago
  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 https://en.wikipedia.org/wiki/Accent_kernel.
junon 2y ago
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 2y ago
  > 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 https://news.ycombinator.com/item?id=15800676
  - hunter2_ 2y ago
    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.
    - internetter 2y ago
      https://gh-api.clickhouse.tech/play?user=play#U0VMRUNUIGRlc2NlbmRhbnRzLCBDT05DQVQoJ2h0dHBzOi8vbmV3cy55Y29tYmluYXRvci5jb20vaXRlbT9pZD0nLCBpZCkgQVMgaWQsIHVybCwKRlJPTSBoYWNrZXJuZXdzCk9SREVSIEJZIGRlc2NlbmRhbnRzIERFU0MKTElNSVQgMTAwOw== https://gh-api.clickhouse.tech/play?user=play#U0VMRUNUIGRlc2... long live sql
      - hunter2_ 2y ago
        Awesome!
- nmgycombinator 2y ago
  > 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 2y ago
    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 2y ago
      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)
    - junon 2y ago
      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 2y ago
        Oh nice! Do you have a GitHub or something for the kernel?
        junon 2y ago
        https://GitHub.com/oro-os/kernel https://GitHub.com/oro-os/kernel :) Still in early stages of development, mind you.
- technothrasher 2y ago
  > "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 2y ago
    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-computers-connect-mac-mchlp3015/15.0/mac/15.0 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 2y ago
      >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 2y ago
        > 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.
- jonathanstrange 2y ago
  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 2y ago
    Damn, that's honestly hilarious.
    - oneplane 2y ago
      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 2y ago
        > manually unlocked a local Keychain Does the Keychain stay unlocked for a while? And do people actually do this?
        oneplane 2y ago
        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.
- seppler 2y ago
  I also submitted a report for CVE-2011-3226 for a password-less login, referenced here: https://support.apple.com/en-us/103345 https://support.apple.com/en-us/103345
- bobbylarrybobby 2y ago
  Don't forget the time that Apple would show your password in plaintext instead of your password hint: https://news.ycombinator.com/item?id=15410953 https://news.ycombinator.com/item?id=15410953 “If a hint was set in Disk Utility when creating an APFS encrypted volume, the password was stored as the hint. This was addressed by clearing hint storage if the hint was the password, and by improving the logic for storing hints.”
turnsout 2y ago
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 2y ago
  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 2y ago
  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.
unit149 2y ago
[dead]
biofunsf 2y ago
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 2y ago
  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 2y ago
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/2bdce1c0c76c7adc360e17a6a42ee547462b99d3 https://github.com/nmggithub/wts/commit/2bdce1c0c76c7adc360e... Just a one word change, fixing a factual inaccuracy when talking about how XNU works.
nixpulvis 2y ago
"ACLs don't": https://waterken.sourceforge.net/aclsdont/current.pdf https://waterken.sourceforge.net/aclsdont/current.pdf
- nmgycombinator 2y ago
  Great article! Thanks for the link!
nmgycombinator 2y ago
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!
corank 2y ago
> 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 https://en.wikipedia.org/wiki/Confused_deputy_problem A capability-based design should be able to systematically prevent this kind of problems.
- nmgycombinator 2y ago
  > A capability-based design should be able to systematically prevent this kind of problems. I think Entitlements could be considered a type of capability? And if so, then you're right on your this point, as the solution was to require an entitlement to talk to the daemon itself.
kokonoko 2y ago
A very detailed article. Love the history of all the kernels too. My only minor gripe is that since it's about a serious security issue, I would like a very brief explanation in the beginning, like what is the impact, the requirements for the attack, is it a logic error or memory corruption etc. Very brief, only long enough to know if I want to read the rest of the article or not :)
- nmgycombinator 2y ago
  Thanks for the feedback! I was burying the lede a bit on purpose to entice the reader to read more, but I also completely understand your perspective as well.

A very interesting article this is. Never knew there was so much lore in the making of the Mach and Darwin kernels .

nmgycombinator 2y ago
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 https://en.wikipedia.org/wiki/Accent_kernel.

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 2y ago
> 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 https://news.ycombinator.com/item?id=15800676
- hunter2_ 2y ago
  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.
  - internetter 2y ago
    https://gh-api.clickhouse.tech/play?user=play#U0VMRUNUIGRlc2NlbmRhbnRzLCBDT05DQVQoJ2h0dHBzOi8vbmV3cy55Y29tYmluYXRvci5jb20vaXRlbT9pZD0nLCBpZCkgQVMgaWQsIHVybCwKRlJPTSBoYWNrZXJuZXdzCk9SREVSIEJZIGRlc2NlbmRhbnRzIERFU0MKTElNSVQgMTAwOw== https://gh-api.clickhouse.tech/play?user=play#U0VMRUNUIGRlc2... long live sql
    - hunter2_ 2y ago
      Awesome!
nmgycombinator 2y ago
> 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 2y ago
  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 2y ago
    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)
  - junon 2y ago
    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 2y ago
      Oh nice! Do you have a GitHub or something for the kernel?
      - junon 2y ago
        https://GitHub.com/oro-os/kernel https://GitHub.com/oro-os/kernel :) Still in early stages of development, mind you.
technothrasher 2y ago
> "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 2y ago
  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-computers-connect-mac-mchlp3015/15.0/mac/15.0 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 2y ago
    >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 2y ago
      > 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.
jonathanstrange 2y ago
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 2y ago
  Damn, that's honestly hilarious.
  - oneplane 2y ago
    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 2y ago
      > manually unlocked a local Keychain Does the Keychain stay unlocked for a while? And do people actually do this?
      - oneplane 2y ago
        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.
seppler 2y ago
I also submitted a report for CVE-2011-3226 for a password-less login, referenced here: https://support.apple.com/en-us/103345 https://support.apple.com/en-us/103345
bobbylarrybobby 2y ago
Don't forget the time that Apple would show your password in plaintext instead of your password hint: https://news.ycombinator.com/item?id=15410953 https://news.ycombinator.com/item?id=15410953 “If a hint was set in Disk Utility when creating an APFS encrypted volume, the password was stored as the hint. This was addressed by clearing hint storage if the hint was the password, and by improving the logic for storing hints.”

turnsout 2y ago

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 2y ago
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 2y ago
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.

unit149 2y ago

[dead]

biofunsf 2y ago

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 2y ago
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 2y ago

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/2bdce1c0c76c7adc360e17a6a42ee547462b99d3 https://github.com/nmggithub/wts/commit/2bdce1c0c76c7adc360e... Just a one word change, fixing a factual inaccuracy when talking about how XNU works.

nixpulvis 2y ago

"ACLs don't": https://waterken.sourceforge.net/aclsdont/current.pdf https://waterken.sourceforge.net/aclsdont/current.pdf

nmgycombinator 2y ago
Great article! Thanks for the link!

nmgycombinator 2y ago

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!

corank 2y ago

> 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 https://en.wikipedia.org/wiki/Confused_deputy_problem A capability-based design should be able to systematically prevent this kind of problems.

nmgycombinator 2y ago
> A capability-based design should be able to systematically prevent this kind of problems. I think Entitlements could be considered a type of capability? And if so, then you're right on your this point, as the solution was to require an entitlement to talk to the daemon itself.

kokonoko 2y ago

A very detailed article. Love the history of all the kernels too. My only minor gripe is that since it's about a serious security issue, I would like a very brief explanation in the beginning, like what is the impact, the requirements for the attack, is it a logic error or memory corruption etc. Very brief, only long enough to know if I want to read the rest of the article or not :)

nmgycombinator 2y ago
Thanks for the feedback! I was burying the lede a bit on purpose to entice the reader to read more, but I also completely understand your perspective as well.