Boffins reveal password-killer 0days for iOS and OS X • Hacker News Board

Re: Boffins reveal password-killer 0days for iOS and OS X

#111

Post by eridius » Wed, Jun 17, 2015, 6:30 PM UTC

andor wrote: post #16

Quick summary of the keychain "crack": Keychain items have access control lists, where they can whitelist applications, usually only themselves. If my banking app creates a keychain item, malware will not have access. But malware can delete and recreate keychain items, and add both itself and the banking app to the ACL. Next time the banking app needs credentials, it will ask me to reenter them, and then store them i…

Just to note, this "crack" can be worked around by the banking app. If it finds a keychain item that doesn't have a password, instead of updating the item, it could just delete it and re-create it. That would reset the ACL back to the expected value. (Or it could clear out the ACL, but it's cleaner just to delete/recreate).

That said, this doesn't fix the case tptacek listed where a malicious app could include helpers registered to the bundle ID of another app and those helpers would be automatically added to the ACL of those other apps. If that's an accurate description it sounds like something only Apple can fix.

Re: Boffins reveal password-killer 0days for iOS and OS X

#112

Post by eridius » Wed, Jun 17, 2015, 6:51 PM UTC

DennisP wrote: post #31

userbinator wrote: post #29

Earlier quoted context omitted.

It's not remotely exploitable --- it requires installing a malicious app ; that makes it far less severe than something that could be done through e.g. just visiting a webpage.

Yes, but the researchers submitted an app with the exploit to the app store, and it was accepted.

I bet it was submitted before they informed Apple of the problem. If you were to submit such an app today, it seems likely that they now look for stuff like this.

Re: Boffins reveal password-killer 0days for iOS and OS X

#113

Post by tptacek » Wed, Jun 17, 2015, 6:52 PM UTC

justonepost wrote: post #108

tptacek wrote: post #103

It's not bad work but it looks like The Register has hyped it much too far. Breakdown: * OSX (but not iOS) apps can delete (but not read) arbitrary Keychain entries and create new ones for arbitrary applications. The creator controls the ACL. A malicious app could delete another app's Keychain entry, recreate it with itself added to the ACL, and wait for the victim app to repopulate it. * A malicious OSX (but not iOS…

Not sure the above is entirely complete (though perhaps accurate), at least given what they are claiming. They are claiming in the introduction that the WebSocket attack can work on Windows and iOS. However, they don't seem to explain how in section 3.3 My guess is they're saying that an app can create a BG server on an iOS device and you can't control which apps connect to it. Not particularly insightful. I'm skepti…

Their Websockets attack appears to be premised on a Safari extension that assumes it can trust a Websockets endpoint bound to localhost.

Re: Boffins reveal password-killer 0days for iOS and OS X

#114

Post by tptacek » Wed, Jun 17, 2015, 6:53 PM UTC

eridius wrote: post #109

tptacek wrote: post #103

It's not bad work but it looks like The Register has hyped it much too far. Breakdown: * OSX (but not iOS) apps can delete (but not read) arbitrary Keychain entries and create new ones for arbitrary applications. The creator controls the ACL. A malicious app could delete another app's Keychain entry, recreate it with itself added to the ACL, and wait for the victim app to repopulate it. * A malicious OSX (but not iOS…

Thank you for posting this. This is dramatically different from the way The Register was hyping it. It's pretty serious of course, but the iOS vulnerability is pretty minimal[1], and yet The Register made it sound like the keychain was exploited on iOS and it seems that's not the case at all. [1] How often is that even going to be exploitable? Generally cross-app communication like that is to request info from the ot…

No, iOS applications definitely (ab)use URL schemes to send sensitive information or trigger sensitive actions. The problem isn't that they're wrong about that; it's that it's not a new concern.

Re: Boffins reveal password-killer 0days for iOS and OS X

#115

Post by PhantomGremlin » Wed, Jun 17, 2015, 6:59 PM UTC

SlashmanX wrote: post #23

The paper in question: http://arxiv.org/abs/1505.06836

Thank you for that "normal" link.

The Register instead links to something on Google Drive. Since I don't enable JS, Google presents me with an unusable screen of 25 https: links.

Re: Boffins reveal password-killer 0days for iOS and OS X

#116

Post by logfromblammo » Wed, Jun 17, 2015, 7:07 PM UTC

acdha wrote: post #100

carlosrg wrote: post #99

Earlier quoted context omitted.

Well, the UNIX case is not a bug, it's by design. A directory is a list of files, so you remove a file by removing it from that list, the directory. The permissions of the file itself are for access/modifying of the contents of the file itself.

That's technically correct but it violates the principle of least surprise. Most users find the behaviour unexpected even though it's fairly easy to remember and real-world analogues abound (e.g. you can shred an envelope without reading the contents). It's not clear to me that this is a common-enough situation to warrant changing anything so the best answer is probably to make sure documentation is easily found.

It seems like under these conditions--

  1. The user has write permission for the directory.
  2. The user does not have write permission for the file.
  3. The file has only one hard link.
  4. The user deletes the file.

--that the last hard link should be moved to ~owner home directory, rather than deleted. Otherwise, I don't see a problem.

Re: Boffins reveal password-killer 0days for iOS and OS X

#117

Post by eridius » Wed, Jun 17, 2015, 7:33 PM UTC

tptacek wrote: post #114

eridius wrote: post #109

Earlier quoted context omitted.

Thank you for posting this. This is dramatically different from the way The Register was hyping it. It's pretty serious of course, but the iOS vulnerability is pretty minimal[1], and yet The Register made it sound like the keychain was exploited on iOS and it seems that's not the case at all. [1] How often is that even going to be exploitable? Generally cross-app communication like that is to request info from the ot…

No, iOS applications definitely (ab)use URL schemes to send sensitive information or trigger sensitive actions. The problem isn't that they're wrong about that; it's that it's not a new concern.

The only example that really comes to mind where actual secret information is sent over a URL like that is things like Dropbox OAuth tokens, which require the requesting app to have a URL scheme db- that it uses to send the the token. But besides the fact that this isn't a new issue, it's hard to imagine this actually being a serious problem, because it's impossible for the malware app to hide the fact that it just intercepted the URL request. If I'm in some app and request access to Dropbox, it switches to the Dropbox app and asks for permission, and then switches to some other app, it's pretty obvious that other app is behaving badly. Especially since there's no way for that other app to then hand the token back to the original app, so you can't even man-in-the-middle and hope the user isn't paying attention.

Re: Boffins reveal password-killer 0days for iOS and OS X

#118

Post by acdha » Wed, Jun 17, 2015, 7:37 PM UTC

logfromblammo wrote: post #116

acdha wrote: post #100

Earlier quoted context omitted.

That's technically correct but it violates the principle of least surprise. Most users find the behaviour unexpected even though it's fairly easy to remember and real-world analogues abound (e.g. you can shred an envelope without reading the contents). It's not clear to me that this is a common-enough situation to warrant changing anything so the best answer is probably to make sure documentation is easily found.

It seems like under these conditions-- 1. The user has write permission for the directory. 2. The user does not have write permission for the file. 3. The file has only one hard link. 4. The user deletes the file. --that the last hard link should be moved to ~owner home directory, rather than deleted. Otherwise, I don't see a problem.

Again, I'm not sure this happens very often – most projects have tended to focus on avoiding cases where you have users crossing security boundaries like this. At the very least, setting the sticky bit seems to avoid a great deal of potential confusion.

I haven't thought about this in depth but here are the edge cases which come to mind on first thought with your proposal:

1. What happens if that file is on a different filesystem than the owner's home directory? 1a. What if the home directory is on a filesystem which doesn't have room? 1b. What happens if that would cause the user to exceed a size or inode quota?

2. How does this interact with e.g. lockd in an NFS environment?

3. How does it get a filename / how do we avoid security issues? For example, if I have write access to a directory I can rename the file to, say, .bashrc before I call unlink() so this would probably require generated some sort of reasonably informative name which can't collide ("deleted-by-----"?).

You could probably handle some of this by following the tradition of `lost+found` and moving it to a directory on the same filesystem which has the sticky bit set.

Re: Boffins reveal password-killer 0days for iOS and OS X

#119

Post by tptacek » Wed, Jun 17, 2015, 7:38 PM UTC

eridius wrote: post #117

tptacek wrote: post #114

Earlier quoted context omitted.

No, iOS applications definitely (ab)use URL schemes to send sensitive information or trigger sensitive actions. The problem isn't that they're wrong about that; it's that it's not a new concern.

The only example that really comes to mind where actual secret information is sent over a URL like that is things like Dropbox OAuth tokens, which require the requesting app to have a URL scheme db- that it uses to send the the token. But besides the fact that this isn't a new issue, it's hard to imagine this actually being a serious problem, because it's impossible for the malware app to hide the fact that it just i…

It's less common with the major well-known applications, in part because almost all of those get some kind of security assessment done, and, like I said: this was for a long time the #1 action item on any mobile app assessment.

What you have to keep in mind is that for every major app you've heard of, there are 2000+ that you've never heard of but that are important to some niche of users.

Re: Boffins reveal password-killer 0days for iOS and OS X

#120

Post by eridius » Wed, Jun 17, 2015, 7:40 PM UTC

dodongogo wrote: post #101

It sounds like a temporary fix for the keychain hack on iOS would be to just never use the SecItemUpdate keychain API, and always use SecItemDelete followed by SecItemAdd with the updated data which according to http://opensource.apple.com/source/Security/Security-55471/s... : > @constant kSecAttrAccessGroup ...Unless a specific access group is provided as the value of kSecAttrAccessGroup when SecItemAdd is called, n…

The keychain hack can't apply to iOS. Each app (well, app group, but an app group can only contain apps by a single developer) gets an independent keychain.