Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

theregister.co.uk

Post reply on HN
Print view View original

91–100 of 144 posts

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

#91

Post by gpvos »

smtddr wrote: post #89
gpvos wrote: post #21

Earlier quoted context omitted.

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.

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

The sticky bit, often applied to directories like /tmp, fixes this: https://en.wikipedia.org/wiki/Sticky_bit .

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

#92

Post by walterbell »

reitanqild wrote: post #53
tempodox wrote: post #46

Earlier quoted context omitted.

No idea. I can't even find a single obvious interpretation of what a downvote is supposed to convey. I bet it's not the same thing twice for the same person on the same day. If it were up to me, I would remove the power-to-downvote from the API. If I really do oppose a comment, I should give a reason rather than just a “bit with a negative sign”.

One reason is people using HN on mobile devices. This used to be my "reading account" so I couldn't downvote accidentally but now I have crossed the barrier with this one as well. Not saying that is what happened here though (because I down't know.)

Yes, we need the upvote and downvote icons to be moved to opposite ends of the comment title, which would eliminate the 1mm targeting challenge.

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

#93

Post by bobbyi_settv »

sigzero wrote: post #58
romanovcode wrote: post #49

Earlier quoted context omitted.

>Just like Windows. Strange thing eh? Not strange if you grasp the fact that malware is just a program that has elevated access. For me it was strange how can Apple market their system as virus-free. Now that's ridiculous.

I have never seen Apple market their system as "virus free". Can you point me to that one?

It was a ubiquitous part of Apple's marketing for many years. Their two main (almost only) arguments for overpaying for their computers were that they were "easier" and didn't get viruses.

For example, read through Adweek's summary of Apple's "Get a Mac" campaign, which Adweek calls the best ad campaign of 2000-2010:

http://www.adweek.com/adfreak/apples-get-mac-complete-campai...

"PC has caught a virus and is clearly under the weather. He warns Mac to stay away from him, citing 114,000 known viruses that infect PCs. But Mac isn't worried, as viruses don't affect him."

"Trying to hide from spyware, PC is seen wearing a trench coat, a fedora, dark glasses, and a false mustache. He offers Mac a disguise, but Mac declines, saying he doesn't have to worry about such things with OS X."

"PC appears wearing a biohazard suit to protect himself from viruses and malware. He eventually takes mask off to hear Mac better, then shrieks and puts it back on."

"She has lots of demands, but her insistence that the computer have no viruses, crashes or headaches sends all the PCs fleeing"

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

#94

Post by mordocai »

Someone wrote: post #87
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…

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)

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.

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

#95

Post by hmage »

whoiskevin wrote: post #70
sigzero wrote: post #58

Earlier quoted context omitted.

I have never seen Apple market their system as "virus free". Can you point me to that one?

Easy. https://m.youtube.com/watch?v=GQb_Q8WRL_g

Which was never aired since 2010, removed everywhere from Apple's website and youtube channels.

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

#96

Post by redbeard0x0a »

draugadrotten wrote: post #25
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…

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.

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.

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

#97

Post by MagerValp »

kinofcain wrote: post #77
MagerValp wrote: post #37

That paper is rife with confusing or just plain wrong terminology, and the discussion jumps between Android, iOS, and OS X, making it really hard to digest. I think these are the bugs they have discovered, but if anyone could clarify that would be great: • The keychain can be compromised by a malicious app that plants poisoned entires for other apps, which when they store entries that should be private end up readabl…

The URL Schemes are unauthenticated, but the main problem is that duplicates are resolved by the host OS at install time, either as first-installed app wins (OSX) or last installed app wins (iOS).

Both of which seem like a valid strategy to me. The OS has never guaranteed that a particular URL scheme goes to a particular app, and developers are wrong to assume that it goes to their app and not someone else's. I realize that there aren't that many alternatives on iOS, but a sharing extension at least gives the user complete control. On OS X there are a wealth of different IPC options, including sockets and mach based services.

It would of course be nice if Apple provided a nice GUI to control the Launch Services database, but since they haven't you have to assume that users are neither in control nor aware of which app handles which URL scheme.

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

#99

Post by carlosrg »

gpvos wrote: post #21
davotoula wrote: post #20

Earlier quoted context omitted.

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

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.

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.

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

#100

Post by acdha »

carlosrg wrote: post #99
gpvos wrote: post #21

Earlier quoted context omitted.

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.

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.

Post reply on HN