9

On OS X, when an application requests access to a Keychain item, the user is prompted whether to grant or deny that access.

Supposedly, the system saves not only the binary path, but also its hash in the ACL entry that is created after the user confirms the request; according to Apple, this protects against modified binaries gaining access to user passwords and/or certificates.

Is this really sufficient to prevent an attacker with user (but not superuser) permissions from retrieving all stored passwords?

On Linux, for example, there is the environment variable LD_PRELOAD which can be used to load additional dynamic libraries that overwrite some standard library functions with custom code; using that, it would seem to be possible to change the code that is executed within a given binary without modifying the base executable itself.

Is there a similar mechanism on OS X that would enable such an attack (maybe one of the methods mentioned here)?

lxgr
  • 4,094
  • 3
  • 28
  • 37
  • It is pretty secure in my opinion, It was initially part of the apple email system power talk but fell apart. Apple has always been secret on what encryption schemes they use but its not easy to retrieve passwords from keychain – Morpheus Jul 30 '14 at 12:23

4 Answers4

2

The security boundary is root, i.e. securityd running as root. If securityd and it's ACL are implemented correctly, there is no way for another application to access the key from the keychain. However, Mac OS X has had several privilege escalation vulnerabilities which would allow a local user attacker to access securityd and thus the item from the keychain. It is reasonable to assume that a moderately/highly skilled attacker could still find existing privilege escalation 0day.

fel1x
  • 389
  • 1
  • 5
1

As I understand it, securityd is the process that interprets & enforces the keychain ACLs. The code/libraries in your application communicate with securitd via xpc messages. Securityd is the one that opens the keychain file, so code injection or dyld library bypass in the calling application won't be able to change the amount of access you may have. As fel1x mentions, that leaves breaking into/subverting securityd. I know that launchd has special code to deal with securityd, such as it won't relaunch securityd if it crashes, you have to reboot to recover the system. There may be other protections as well. A simple root escalation may not be enough to subvert securityd.

Leland Wallace
  • 201
  • 1
  • 3
0

As I understand it, yes, security interprets and enforces the keychain ACLs. However, those are in the form of entitlements. So in the case of privilege escalation (not necessarily a zero day; even a jailbreak may be sufficient), an attacker app can give itself the appropriate entitlements to use your app's keys, no matter how well "protected" they are in the keychain (never leaving the keychain, etc.).

auspicious99
  • 493
  • 3
  • 17
0

for all of we know, OSX's developer try really hard to protect and encrypt the data in the keychain, and like other applications (firefox, even windows auth's), you can access it with a password, the only real attack that would work at the moment, is either keylogging when accessing such thing as a keychain, or by bruteforcing/dictionary attack the "password" field, since those aplpications do not have a "lockout" function after i.e. 5 tries in 1 minute

Lighty
  • 2,368
  • 1
  • 23
  • 36