7 ms·

Quick summary of the keychain "crack": Keychain items have access control lists, where they can whitelist applications, usually only themselves. If my banking

by andor 11y ago

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 in the keychain item created by the malware.

davotoula 11y ago
How can malware delete a keychain item if it is not on the ACL?
- gpvos 11y ago
  Apparently everyone can. That's the bug, or at least a big part of it. There is precedent for this, for example in the Unix filesystem permissions: to be able to delete a file, you need write access to its parent directory; the permissions of the file itself are not taken into account.
  - smtddr 11y ago
    >>There is precedent for this, for example in the Unix filesystem permissions: to be able to delete a file, you need write access to its parent directory; the permissions of the file itself are not taken into account. My mind has been blown. I can delete this .txt as the user "pikachu". I had no idea. pikachu@POKEMONGYM ~/tmp3/pikachuFolder $ ls -la total 8 drwxrwxr-x 2 pikachu pikachu 4096 Jun 17 08:48 . drwxr-xr-x 3 pikachu pikachu 4096 Jun 17 08:48 .. -rw-r--r-- 1 root root 0 Jun 17 08:48 gogogadgetarms.txt pikachu@POKEMONGYM ~/tmp3/pikachuFolder $ pikachu@POKEMONGYM ~/tmp3/pikachuFolder $ rm gogogadgetarms.txt rm: remove write-protected regular empty file ‘gogogadgetarms.txt’? y pikachu@POKEMONGYM ~/tmp3/pikachuFolder $ ls -la total 8 drwxrwxr-x 2 pikachu pikachu 4096 Jun 17 08:52 . drwxr-xr-x 3 pikachu pikachu 4096 Jun 17 08:48 .. pikachu@POKEMONGYM ~/tmp3/pikachuFolder $
    - gpvos 11y ago
      The sticky bit, often applied to directories like /tmp, fixes this: https://en.wikipedia.org/wiki/Sticky_bit https://en.wikipedia.org/wiki/Sticky_bit .
    - syncsynchalt 11y ago
      The thinking is that if you own the directory you own the ability to remove things from it. It gets reported as a bug quite often though.
  - carlosrg 11y ago
    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.
    - acdha 11y ago
      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.
      - logfromblammo 11y ago
        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.
        acdha 11y ago
        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-<uid>-<hostname>-<inode>-<SHA-256>-<sequence>"?). 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.
draugadrotten 11y ago
Is there a known exploit in the wild? Mac Outlook have (for unknown reasons) been asking me for my domain password to store it into the keychain, the last week, which surprised me at the time.
- redbeard0x0a 11y ago
  Mac Outlook has a tendency to ask for the password in that manner if there are network changes or connection problems when it is trying to connect/reconnect/etc.
pilsetnieks 11y ago
If this is how it works, you can check it on OS X by clicking each item in Keychain Access and looking at the Access Control tab or you can run `security dump-keychain -a` in terminal - it lists all keychain items and their access control lists. It's still a big and unwieldy list but not as bad as clicking each keychain item. Someone better at this stuff could probably think of a way to make it easier. (This would only show if you've been exploited already, not that some app is capable of doing it.)
- obituary_latte 11y ago
  >This would only show if you've been exploited already What would indicate a compromise?
  - alimbada 11y ago
    If the ACL of a keychain item contains an app that isn't supposed to have access to that keychain item then that would indicate a compromise.
    - obituary_latte 11y ago
      Ah ok that makes sense. Thanks very much.
- MaysonL 11y ago
  I'm curious: do you have any idea why after running this command would security start asking for password for various keychains?
  - pilsetnieks 11y ago
    It goes over all keychains so I'm assuming (at least it was so for me) that it asked for password for locked keychains. `security` is a built-in system utility, basically Keychain Access for terminal, the same way that `diskutil` is Disk Utility but in the terminal.
- 11y ago
Someone 11y ago
Malware apparently can also create items in advance as a sort-of honeypot for passwords. For me, that is worse, as when "Next time the banking app needs credentials, it will ask me to reenter them" would occur, my reaction would be "I do not know my password; it's in the keychain" (for most services)
- mordocai 11y ago
  I'd imagine that unless you suspect an attack, at that point you'd reset your password and enter it into the keychain: Giving them your new password.
  - Someone 11y ago
    First one? Probably. If it happened twice or thrice within a few hours, I would start being suspicious and reach for a backup. But maybe, I'm too paranoid.
eridius 11y ago
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.

by andor 11y ago

davotoula 11y ago

How can malware delete a keychain item if it is not on the ACL?

gpvos 11y ago
Apparently everyone can. That's the bug, or at least a big part of it. There is precedent for this, for example in the Unix filesystem permissions: to be able to delete a file, you need write access to its parent directory; the permissions of the file itself are not taken into account.
- smtddr 11y ago
  >>There is precedent for this, for example in the Unix filesystem permissions: to be able to delete a file, you need write access to its parent directory; the permissions of the file itself are not taken into account. My mind has been blown. I can delete this .txt as the user "pikachu". I had no idea. pikachu@POKEMONGYM ~/tmp3/pikachuFolder $ ls -la total 8 drwxrwxr-x 2 pikachu pikachu 4096 Jun 17 08:48 . drwxr-xr-x 3 pikachu pikachu 4096 Jun 17 08:48 .. -rw-r--r-- 1 root root 0 Jun 17 08:48 gogogadgetarms.txt pikachu@POKEMONGYM ~/tmp3/pikachuFolder $ pikachu@POKEMONGYM ~/tmp3/pikachuFolder $ rm gogogadgetarms.txt rm: remove write-protected regular empty file ‘gogogadgetarms.txt’? y pikachu@POKEMONGYM ~/tmp3/pikachuFolder $ ls -la total 8 drwxrwxr-x 2 pikachu pikachu 4096 Jun 17 08:52 . drwxr-xr-x 3 pikachu pikachu 4096 Jun 17 08:48 .. pikachu@POKEMONGYM ~/tmp3/pikachuFolder $
  - gpvos 11y ago
    The sticky bit, often applied to directories like /tmp, fixes this: https://en.wikipedia.org/wiki/Sticky_bit https://en.wikipedia.org/wiki/Sticky_bit .
  - syncsynchalt 11y ago
    The thinking is that if you own the directory you own the ability to remove things from it. It gets reported as a bug quite often though.
- carlosrg 11y ago
  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.
  - acdha 11y ago
    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.
    - logfromblammo 11y ago
      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.
      - acdha 11y ago
        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-<uid>-<hostname>-<inode>-<SHA-256>-<sequence>"?). 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.

draugadrotten 11y ago

Is there a known exploit in the wild? Mac Outlook have (for unknown reasons) been asking me for my domain password to store it into the keychain, the last week, which surprised me at the time.

redbeard0x0a 11y ago
Mac Outlook has a tendency to ask for the password in that manner if there are network changes or connection problems when it is trying to connect/reconnect/etc.

pilsetnieks 11y ago

If this is how it works, you can check it on OS X by clicking each item in Keychain Access and looking at the Access Control tab or you can run `security dump-keychain -a` in terminal - it lists all keychain items and their access control lists. It's still a big and unwieldy list but not as bad as clicking each keychain item. Someone better at this stuff could probably think of a way to make it easier. (This would only show if you've been exploited already, not that some app is capable of doing it.)

obituary_latte 11y ago
>This would only show if you've been exploited already What would indicate a compromise?
- alimbada 11y ago
  If the ACL of a keychain item contains an app that isn't supposed to have access to that keychain item then that would indicate a compromise.
  - obituary_latte 11y ago
    Ah ok that makes sense. Thanks very much.
MaysonL 11y ago
I'm curious: do you have any idea why after running this command would security start asking for password for various keychains?
- pilsetnieks 11y ago
  It goes over all keychains so I'm assuming (at least it was so for me) that it asked for password for locked keychains. `security` is a built-in system utility, basically Keychain Access for terminal, the same way that `diskutil` is Disk Utility but in the terminal.
11y ago

Someone 11y ago

Malware apparently can also create items in advance as a sort-of honeypot for passwords. For me, that is worse, as when "Next time the banking app needs credentials, it will ask me to reenter them" would occur, my reaction would be "I do not know my password; it's in the keychain" (for most services)

mordocai 11y ago
I'd imagine that unless you suspect an attack, at that point you'd reset your password and enter it into the keychain: Giving them your new password.
- Someone 11y ago
  First one? Probably. If it happened twice or thrice within a few hours, I would start being suspicious and reach for a backup. But maybe, I'm too paranoid.

eridius 11y ago

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.