4 ms·

Does anybody have more information on this claim of a keychain vulnerability in High Sierra... just saw it fly past on Twitter. https://twitter.com/patrickward

Does anybody have more information on this claim of a keychain vulnerability in High Sierra... just saw it fly past on Twitter. https://twitter.com/patrickwardle/status/912254053849079808 https://twitter.com/patrickwardle/status/912254053849079808 >on High Sierra (unsigned) apps can programmatically dump & exfil keychain (w/ your plaintext passwords) vid: https://player.vimeo.com/video/235313957 https://player.vimeo.com/video/235313957 #smh

delinka 9y ago
I’d like a bit more detail. Instructions to repro ideally. Too much is left out of the video (show me the items it will access and the access permissions for those items) and I’m inclined to think it’s staged or Mr. Wardle didn’t understand something fundamental (e.g. if you built/debugged the app on the same system where you made the video, you may have already authorized the app to fetch items from the keychain.)
- mvdwoord 9y ago
  So would I.. normally quick to dismiss. I'm not familiar with Mr Wardle, but he seems to have some serious followers. I was hoping someone here has some background information.
- benashford 9y ago
  It showed the "unknown developer" warning box when running the app, would that have been shown if the app was already authorised to access the keychain?
  - delinka 9y ago
    Yes. It's not "access to the keychain" but "access to this item" and it's a simple "the binary $NAME with $DIGEST has permission to access this item." Technically, if you can create another executable binary with the same name and digest, you can access the same keychain item.
    - jakobegger 9y ago
      nope. Keychain checks the code signature of the app.
      - delinka 9y ago
        Finding that hard to believe if the binary isn't code-signed.
        jakobegger 9y ago
        You are right, I initially misread your comment, I thought it said that Keychain only checks the app name. The security framework uses some kind of digest / signature to verify that the app hasn't changed if the binary is not code signed. Apple's docs are scarce on details, see eg [1] which just says that the security framework makes sure the app wasn't altered. But I am pretty sure the app name is ignored. Most macOS services use the bundle identifier. However, if the app is code signed, the security framework automatically grants newer versions of the app permission if they have been signed with the same certificate. [1]: https://developer.apple.com/documentation/security/1400622-sectrustedapplicationcreatefromp?language=objc https://developer.apple.com/documentation/security/1400622-s...
EwanToo 9y ago
That seems insane, but the tweeter and the video appear legitimate
wila 9y ago
There's another HN topic about that here: https://news.ycombinator.com/item?id=15329527 https://news.ycombinator.com/item?id=15329527
thought_alarm 9y ago
Hasn't that always been the case? Years ago I moved all of my important passwords to a secondary keychain that remains locked for precisely this reason.
altitudinous 9y ago
It doesn't seem like a real vulnerabilty to me - it is not remotely executable, it has to be run by a signed in user on the actual device. When you go to facebook.com, your device must surely decrypt the keychain to plaintext to prefill the password field so it can send your password to facebook.com - Thats how it works. So this seems like normal functionality to me, someone has just put it in a command line. Someone has just reverse engineered the keychain decrypt that happens all the time. Am I missing something?
- aardshark 9y ago
  Yes. When an app accesses the keychain a dialog box is presented to the user with "Allow", "Always Allow" and "Deny". If "Always Allow" is chosen, then the app will have permanent permission to access _only_ that particular password in the keychain. This vunerability appears to bypass that dialog entirely and dump the entire keychain in plaintext without requiring the users permisson.
- thefreeman 9y ago
  Yes, you are completely missing how the keychain works. When you go to facebook.com, safari requests access to the facebook.com password via the keychain api. At which point you are supposed to be prompted by the OS, and if you allow it, the keychain api returns the decrypted password only for facebook.com. The vulnerability being demonstrated is able to decrypt every password in your keychain, without prompting the user in any way.
  - eugeniub 9y ago
    When I go to Facebook.com, my login credentials are instantly filled in by Safari. What prompt are you talking about?
    - jakobegger 9y ago
      You either gave Safari permission before, or Safari was the app that added the password to the keychain in the first place.

delinka 9y ago

I’d like a bit more detail. Instructions to repro ideally. Too much is left out of the video (show me the items it will access and the access permissions for those items) and I’m inclined to think it’s staged or Mr. Wardle didn’t understand something fundamental (e.g. if you built/debugged the app on the same system where you made the video, you may have already authorized the app to fetch items from the keychain.)

mvdwoord 9y ago
So would I.. normally quick to dismiss. I'm not familiar with Mr Wardle, but he seems to have some serious followers. I was hoping someone here has some background information.
benashford 9y ago
It showed the "unknown developer" warning box when running the app, would that have been shown if the app was already authorised to access the keychain?
- delinka 9y ago
  Yes. It's not "access to the keychain" but "access to this item" and it's a simple "the binary $NAME with $DIGEST has permission to access this item." Technically, if you can create another executable binary with the same name and digest, you can access the same keychain item.
  - jakobegger 9y ago
    nope. Keychain checks the code signature of the app.
    - delinka 9y ago
      Finding that hard to believe if the binary isn't code-signed.
      - jakobegger 9y ago
        You are right, I initially misread your comment, I thought it said that Keychain only checks the app name. The security framework uses some kind of digest / signature to verify that the app hasn't changed if the binary is not code signed. Apple's docs are scarce on details, see eg [1] which just says that the security framework makes sure the app wasn't altered. But I am pretty sure the app name is ignored. Most macOS services use the bundle identifier. However, if the app is code signed, the security framework automatically grants newer versions of the app permission if they have been signed with the same certificate. [1]: https://developer.apple.com/documentation/security/1400622-sectrustedapplicationcreatefromp?language=objc https://developer.apple.com/documentation/security/1400622-s...

EwanToo 9y ago

That seems insane, but the tweeter and the video appear legitimate

wila 9y ago

There's another HN topic about that here: https://news.ycombinator.com/item?id=15329527 https://news.ycombinator.com/item?id=15329527

thought_alarm 9y ago

Hasn't that always been the case? Years ago I moved all of my important passwords to a secondary keychain that remains locked for precisely this reason.

altitudinous 9y ago

It doesn't seem like a real vulnerabilty to me - it is not remotely executable, it has to be run by a signed in user on the actual device. When you go to facebook.com, your device must surely decrypt the keychain to plaintext to prefill the password field so it can send your password to facebook.com - Thats how it works. So this seems like normal functionality to me, someone has just put it in a command line. Someone has just reverse engineered the keychain decrypt that happens all the time. Am I missing something?

aardshark 9y ago
Yes. When an app accesses the keychain a dialog box is presented to the user with "Allow", "Always Allow" and "Deny". If "Always Allow" is chosen, then the app will have permanent permission to access _only_ that particular password in the keychain. This vunerability appears to bypass that dialog entirely and dump the entire keychain in plaintext without requiring the users permisson.
thefreeman 9y ago
Yes, you are completely missing how the keychain works. When you go to facebook.com, safari requests access to the facebook.com password via the keychain api. At which point you are supposed to be prompted by the OS, and if you allow it, the keychain api returns the decrypted password only for facebook.com. The vulnerability being demonstrated is able to decrypt every password in your keychain, without prompting the user in any way.
- eugeniub 9y ago
  When I go to Facebook.com, my login credentials are instantly filled in by Safari. What prompt are you talking about?
  - jakobegger 9y ago
    You either gave Safari permission before, or Safari was the app that added the password to the keychain in the first place.