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

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

#141

Post by logfromblammo » Thu, Jun 18, 2015, 4:44 PM UTC

acdha wrote: post #118

logfromblammo wrote: post #116

Earlier quoted context omitted.

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 differe…

You put a bit more effort into this than I did. I only said the first thing that came to mind that would prevent a user without write permission from deleting the file, which is a near-equivalent to blindly overwriting the contents of a file with nothing.

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

#142

Post by TheLoneWolfling » Thu, Jun 18, 2015, 7:05 PM UTC

logfromblammo wrote: post #140

TheLoneWolfling wrote: post #131

Earlier quoted context omitted.

That's a major security bug waiting to happen. You're effectively granting everyone the right to create files in anyone's home directory.

But you have to be superuser to chown.

That's not the only way to get an arbitrary file owned by someone else.

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

#143

Post by logfromblammo » Thu, Jun 18, 2015, 8:59 PM UTC

TheLoneWolfling wrote: post #142

logfromblammo wrote: post #140

Earlier quoted context omitted.

But you have to be superuser to chown.

That's not the only way to get an arbitrary file owned by someone else.

If there is a way that does not require superuser access at any point in the process, I'm curious. Please tell.

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

#144

Post by peterhil » Sun, Jun 21, 2015, 5:15 PM UTC

pilsetnieks wrote: post #42

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…

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 on…

Here is a more comprehensive one-liner to see all items with more than 1 applications on a ACL list:

    security dump-keychain -a > keychain-results.txt

    grep -P '(^(class|keychain):|\s+("(svce|acct)"|0x0000000(1|7)) ="[^"]*"|^\s+applications \(([2-9]|[0-9]{2,})\):|^\s+[0-9]+:)' keychain-results.txt | \
    perl -pe 's/\n/\0/g' | perl -pe 's/\0keychain:/\nkeychain:/g' | \
    grep -aP 'applications \(([2-9]|[0-9]{2,})\):' | \
    sort -u | perl -pe 's/\0/\n/g'