pastercali.blogg.se - Mac keychain access vulnerability

#Mac keychain access vulnerability mac os x#
#Mac keychain access vulnerability update#
#Mac keychain access vulnerability code#

#Mac keychain access vulnerability update#

We then added the following lines to the test: *// Update the vulnerable keychain value with Valet, and see that we have deleted the existing keychain item (rather than updating it) are therefore no longer vulnerable.*

#Mac keychain access vulnerability code#

Now that we had a compromised value, we changed Valet’s code on OS X to call SecItemDelete followed by SecItemAdd on setObject:forKey. Once we ran this code, we saw the compromised value in the keychain. XCTAssertEqual(SecItemAdd((_bridge CFDictionaryRef)keychainData, NULL), errSecSuccess) (_bridge (_bridge id)trustedAppSelf, (_bridge id)trustedAppSystemUIServer ], XCTAssertEqual(SecAccessCreate((_bridge Control List", XCTAssertEqual(SecTrustedApplicationCreateFromPath("/System/Library/CoreServices/SystemUIServer.app", &trustedAppSystemUIServer), errSecSuccess) XCTAssertEqual(SecTrustedApplicationCreateFromPath(NULL, &trustedAppSelf), errSecSuccess) SecTrustedApplicationRef trustedAppSystemUIServer = NULL SecTrustedApplicationRef trustedAppSelf = NULL NSString ***const** vulnKey **=** ***const** vulnKeyValue **=** Add an entry to the keychain with an access control list. VALValet *****valet **=** accessibility:VALAccessibilityWhenUnlocked] This compromised key is added using the same base query as our test VALValet, so that our valet is able to read and write to the compromised key.

We wanted the test to mimic the attack as closely as possible so we started by inserting a key into the keychain that had multiple applications in the ACL. Our first step was to write a unit test to examine our hypothesis. Better yet, this warning does not apply to Valet, which shares keychain values on OS X and iOS using secure Shared Access Groups rather than ACLs. Why? Because “hen you delete a keychain item, you lose any access controls and trust settings added by the user or by other applications.” While that sounds ominous, it’s just the effect we want. Instead of updating an existing keychain entry when changing the value of an item in the keychain, delete the existing item and then add a new one.īut Apple’s docs are very clear: Do not delete and then add - always update. So, we’re left with just adding and deleting. We cannot trust that an existing key in Keychain does not have a compromised Access Control List. But we now know that on OS X, updating is inherently insecure. A poisoned toolĪpple’s Keychain offers only three tools for updating the keychain: add, update, and delete. This wasn’t acceptable to us, so we hardened Valet against this attack. However we had just open sourced Valet, a cross-platform keychain wrapper, two weeks prior, and its OS X component was vulnerable.

#Mac keychain access vulnerability mac os x#

Malicious app then adds the keys back to the keychain without the values, and adds itself and the benign app to the keys’ Access Control List (ACL), allowing the malicious app to read whatever secrets the benign app later writes to those keys.Īt this point, we could breathe a sigh of relief: Access Control Lists only exist on Mac OS X - not iOS - so despite the headlines, our applications were not vulnerable to an attack.

Malicious app deletes the keys written by the benign apps.

The malicious app can see that the keys exist, but can’t read the associated secret values.

Malicious app searches the Keychain for keys written by benign apps.

We found that the attack worked as follows:

When we became aware of the vulnerability a little after 8am PDT, we immediately opened up the paper describing the attack. If the article’s assertions were correct, the world was on fire. Security is always our first priority, and we took these claims very seriously.

At Square, we write iOS code that moves money. The article claimed that data written to the keychain could be read by a malicious application. On June 17th, The Register reported that there was a zero-day vulnerability in the iOS and OS X Keychain that compromised secure data stored in the Keychain.