10 ms·
Boffins reveal password-killer 0days for iOS and OS X
- deleted 11y ago[deleted]
- therealmarv 11y agoSo Apple was aware of this for 6 months and are doing NOTHING, not even communicating?! How serious do they take security and fixing it (at least within 6 months) ?
- dotpot 11y agoexactly....
- coldtea 11y ago>"and are doing NOTHING" Citation needed. An article (and on the Register at that) is not any indication that "they're doing nothing"...
- mcintyre1994 11y agoThey do make the claim in the paper: > We reported this vulnerability to Apple on Oct. 15, 2014, and communicated with them again in November, 2014 and early 2015. They informed us that given the nature of the problem, they need 6 months to fix it. However, doing nothing seems to be unfair: > We checked the most recent OS X 10.10.3 and beta version 10.10.4 and found that they attempted to address the iCloud issue using a 9-digit random number as accountName. However, the accountName attribute for other services, e.g. Gmail, are still the user’s email address. Most importantly, such protection, based upon a secret attribute name, does not work when the attacker reads the attribute names of an existing item and then deletes it to create a clone under its control, a new problem we discovered after the first keychain vulnerability report and are helping Apple fix it. So not nothing, but their iCloud 'fix' doesn't work and there's no fix for the real issues. But the researchers say they're helping Apple fix it, so nothing does seem unfair.
- webdevsimon 11y agoHow do you know they was aware if they didn't "not even communicating"?
- Oletros 11y agoAccording to the article, they were aware
- huxley 11y agoThis doesn't seem like something a quick patch can fix. The section of the paper on mitigation suggests that it is non-trivial to correct without significantly re-architecting the app-OS relationship, if the paper is accurate, Apple is in a very difficult situation.
- Oletros 11y agoYap, but the OP was saying that perhaps Apple was not aeare of the vulnerability but the article stated that they the authors had communications wiht Apple about it. It seems that stating just a fact from the article is not liked by some
- lgrebe 11y agoFTA: "Apple security officers responded in emails seen by El Reg expressing understanding for the gravity of the attacks and asking for a six month extension and in February requesting an advanced copy of the research paper before it was made public."
- skrowl 11y agoI'm surprised that you're surprised! After The Fappening and the SMS of doom (amongst many others), you can't still believe that Apple gives a sh*t about security, can you? I mean, I understand that there are still a lot of Apple fans here at HN, but Apple's security has been a laughing stock of the industry for a while now.
- frankzinger 11y agoDon't forget 'goto fail'.
- soylentcola 11y agoI'm far from an Apple apologist (I probably complain about them more than I praise them) but "failing to be flawless" about security is not the same thing as "not giving a shit" about security. I've yet to see any massive platform that is both flexible and open to millions of users that has zero security flaws or exploits developed for them. Not saying it's a good thing, but it's certainly a common thing, even among companies that give several shits about security.
- layman 11y agoThere is a difference between "has zero security flaws" and "not fixing a security flaw for 6 months after being made aware"
- userbinator 11y agoIt'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.
- DennisP 11y agoYes, but the researchers submitted an app with the exploit to the app store, and it was accepted.
- mmcconnell1618 11y agoGood thing there are 1,500,000 apps in the store and getting visibility is the biggest challenge for developers/publishers :-)
- DennisP 11y agoThere are lots of web pages too, but an exploit that works when you visit a web page is still a pretty big deal.
- nadams 11y ago"MoneyMakingApp5000 - make money from home" Post some screenshots of the app with screenshots of some random Paypal transfers and I don't think that you will have a problem getting people to find/download your app.
- webjprgm 11y agoDownloading and running it once would set up the exploit but not complete it, IIRC. You need to go back to the target app and re-enter credentials then run the exploit app a second time. So a broken app that a user would run once and then delete is no good. A standard Trojan game/utility would work fine even if only a small number of people run it.
- untog 11y agoAh yes, security by obscurity, everyone's favourite.
- yAnonymous 11y agoApple's stance on security is "fix it when there's an exploit" rather than "fix it when it's broken".
- madaxe_again 11y agoAccording to the paper they haven't done nothing, they cranked out a half-assed fix for the keychain issue specifically for iCloud. So as good as nothing, but not nothing.
- deleted 11y ago[deleted]
- StavrosK 11y ago"Boffins"? Isn't that rather dismissive, as in "oh, look at what those crazy boffins cooked up now!"?
- dghf 11y agoIt's the standard Reg term for scientists and academics.
- zelos 11y agoIt's tongue-in-cheek. The Register's style is basically a joke on British tabloid styles.
- deleted 11y ago[deleted]
- huxley 11y agoBoffin just means someone that has an esoteric or difficult-to-master skill.
- Nexxxeh 11y agoIt's the British IT Tabloid. Its style is not to be taken entirely seriously. See their units convertor: http://www.theregister.co.uk/Design/page/reg-standards-converter.html http://www.theregister.co.uk/Design/page/reg-standards-conve... A! Yahoo! Related! Story! Is! Probably! Headlined! With! Exclamation! Marks! It uses terms like bonk-to-pay (contactless payment), mobes (mobile/cellular phones), Chocolate Factory (Google), Blighty (Britain) etc.
- 0x0 11y agoAnyone have any more information about (or even a source for) "Google's Chromium security team was more responsive and removed Keychain integration for Chrome noting that it could likely not be solved at the application level"? Is this going to happen in an upcoming stable release? What is it being replaced with?
- therealmarv 11y agoChromium security issues are not public visible. At least as long as the security issue remains.
- anon1385 11y agoThat does seem a bit strange. The Chrome devs have long taken the position that there's no point trying to encrypt local copies of passwords. You can see a very long discussion about it here where Chrome devs argue that it's pointless: https://news.ycombinator.com/item?id=6165708 https://news.ycombinator.com/item?id=6165708 The comments by the chrome security tech lead would suggest that they wouldn't view this keychain issue as a security flaw. So I don't see why they would bother removing keychain integration. What is the replacement going to be? A password file encrypted with the password "peanuts"?[1] [1] https://news.ycombinator.com/item?id=9714770 https://news.ycombinator.com/item?id=9714770
- andor 11y agoQuick 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 agoHow can malware delete a keychain item if it is not on the ACL?
- gpvos 11y agoApparently 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 $
- 11y ago
- gchp 11y agoWell, shit. Finally I feel justified for never (read: rarely) using the "Save password", feature in my web browser. Does anyone know if Apple have done anything towards resolving this in the 6 month window they requested? Slightly worrying now that this has been published without a fix from Apple. I don't really download apps very often on my Mac, but probably won't for sure now until I know this has been resolved. Annoying.
- hhsnopek 11y agoYou know this was bound to happen sooner or later. That goes for any encryption technology. Last pass was recently "hacked" as well. You can't trust any crypto tech ;)
- cinquemb 11y agoIn the age of crypto-peddling-as-a-service by large, small companies and individuals alike, as an end all be all to general opsec and the tradeoffs inherit in any decision making (as it is so often common to ignore such elephants in the room with one wave of the "trust the math" wands), It might just be more socially acceptable to just feign surprise :P
- bennyg 11y agoWhich is why "open source all the things" is the way to go for trusting crypto implementations - or at least it's step 1.
- drtse4 11y agoFrom the paper: > Since the issues may not be easily fixed, we built a simple program that detects exploit attempts on OS~X, helping protect vulnerable apps before the problems can be fully addressed. I'm wondering if the tool is publicly accessible, couldn't find any reference to it.
- jdc0589 11y agowas wondering the same thing... finding items with more than 1 application is the important part. so this is a start: security dump-keychain -a > keychain.txt && egrep -n "applications \(([2-9])\)" keychain.txt Then just look at the item that contains those line numbers and see whats up. You will have some show up on an unaffected system. This is what my output looks like: http://puu.sh/ishaP/675695b11e.png http://puu.sh/ishaP/675695b11e.png * disclaimer, that egrep regex is shit.
- c0wb0yc0d3r 11y agoCan you skip the whole writing to file bit, and pipe straight to egrep?
- SlashmanX 11y agoThe paper in question: http://arxiv.org/abs/1505.06836 http://arxiv.org/abs/1505.06836
- PhantomGremlin 11y agoThank 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.
- jusio 11y agoOh God. After reading the paper I wouldn't expect a fix from Apple anytime soon :(
- watmough 11y agoRight, but it's pretty clear from the paper that one major step forward would be for apps to check whether their keychain has been compromised. This is something that apps can go forward with. But doesn't close the door if it was already opened. Overall, this is just a brutal suite of bugs though, and a great paper.
- ikeboy 11y agoI wonder if the new "Rootless" feature prevents this, and if it was developed because of this.
- smackfu 11y agoRootless is more about securing the OS files and processes from malware.
- ikeboy 11y agoIsn't this similar? Rootless is strengthening the sandbox against malware. Anyone on the new Mac version want to test this?
- smackfu 11y agoIt seemed to me like rootless was at a lower level than the sandbox, since arbitrary apps don't run in the sandbox.
- RexRollman 11y agoI don't think so, especially since the Keychain being affected by this is a user file. Rootless protects system files.
- w8rbt 11y agoThe fundamental design flaw of all of these compromised password managers, keychains, etc. is that they keep state in a file. That causes all sorts of problems (syncing among devices, file corruption, unauthorized access, tampering, backups, etc.). Edit - I seldom downvote others and the few times I do, I comment as to why I think the post was inappropriate. What is inappropriate about my post? Few people stop and think about the burden of keeping state and the problems that introduces with password storage. Many even compound the problems by keeping state in the Cloud (solve device syncing issues). It's worth discussing. There are other ways.
- tempodox 11y agoNo 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”.
- reitanqild 11y agoOne 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.)
- walterbell 11y agoYes, we need the upvote and downvote icons to be moved to opposite ends of the comment title, which would eliminate the 1mm targeting challenge.
- opcvx 11y agoWhere should the state be kept, on a server?
- w8rbt 11y ago
- MagerValp 11y agoThat 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 readable by the malicious app. • A malicious app can contain helper apps, and Apple fails to ensure that the helper app has a unique bundle ID, giving it access to another app's sandbox. • WebSockets are unauthenticated. This seems to be by design rather than a bug though, and applications would presumably authenticate clients themselves, or am I missing something? • URL schemes are unauthenticated, again as far as I can tell by design, and not a channel where you'd normally send sensitive data.
- kinofcain 11y agoThe 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).
- MagerValp 11y agoBoth 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.
- kinofcain 11y agoIndeed. The insecurity of the scheme handling is not a new development and should be better known.
- wahsd 11y agoBravo, Apple. Humongous security hole and you don't address it in six months? I hope it's being readied for inclusion in 8.4. We all know how it bruises Apple's ego to have to patch stuff without acting like it'a a feature enhancement.
- josteink 11y agoOnce again goes to show that Apple is mostly interested in the security of its iStore, platform lock down and DRM. I'm not exactly shocked. Just for kicks... Does anyone remember the I'm a PC ads, where macs were magically "secure", couldn't get viruses or hacked or anything? Turns out, with marketshare they can! Just like Windows. Strange thing eh?
- romanovcode 11y ago>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.
- josteink 11y agoYes, to any techie the lie is obvious. I just wonder what the vast userbase of uneducated people (seniors, teen bloggers, ironically education institutions, etc) who moved over to macs because they bought the lie will feel when they too later discover that the promises were a lie. Because unlike Microsoft, Apple doesn't have a battle hardened OS where security has been worked on systematically, for over a decade. And I could have told you the same story years ago. I don't need blatantly obvious bugs like this one to back that claim.
- mmariani 11y ago> who moved over to macs because they bought the lie will feel when they too later discover that the promises were a lie. what? I thought they bought macs so we wouldn't need to give free tech support ;)
- Bud 11y agoThere was no lie. It was true then, and is still clearly and obviously true now, that Mac users have a small fraction of the malware issues that Windows users have. The difference between iOS and Android is even more stark. You're also hilariously wrong about Microsoft having a supposedly "battle-hardened" OS where security has been worked on systematically. OS X is based on BSD Unix, where security has been worked on since the 1970s, before Microsoft even existed. OS X itself is now 15 years old. I administer hundreds of Macs and PCs. I can objectively state that the PCs have about 10-50x as much issues with malware as the Macs have, and those issues are more severe and affect users and admins more. Everyone who manages both Macs and PCs in the enterprise is well-aware of this.
- jpmoral 11y agoOkay, so if a user only retrieve Keychain items manually (unlock keychain, view password, type/paste into app/website) and never allow apps to access it, is s/he safe?
- vbezhenar 11y agoDon't run untrusted apps outside of virtual machines. Too bad that web taught us to trust the code we shouldn't trust. Noscript must be integrated in every browser and enabled by default. Sandboxing was and will be broken.
- coldcode 11y agoThe first defense they can perform is to change the automatic checks in the App Store review process to identify the attack in a malicious app and stop it from being approved. This could be fairly easy, of course Apple doesn't tell anyone what they do in this process so we have no way to verify it. Still you have to identify how the process could be hidden but since it uses known API calls in an uncommon way, I think this is quite doable. The second defense is more complex, changing the way Keychain API works without breaking every app out there is much more complex. Not knowing much about this is implemented it might take a lot of testing to verify a fix without breaking apps. The last thing they can also do is to build a verified system tool that checks the existing keychain for incorrect ACL usage. You can't hide the hack from the system. This way Apple could fix the ACL to not allow incorrect usage and not give access where it doesn't belong. I think this is fairly easy to do since it will break very little. This is why building security is hard no matter who you are and everyone gets it wrong sometimes. At least Apple has the ability to readily (except for point 2) repair the problem, unlike Samsung having to have 800 million phones somehow patched by third parties to fix the keyboard hack.
- glasz 11y agothey've known for half a year and still, just 2 weeks back, cook is cooking things up about their stance on encryption and privacy [0]. you've gotta love the hypocrisy on every side of the discussion. it's so hilarious that it makes me wanna do harm to certain people. [0] http://9to5mac.com/2015/06/02/tim-cook-privacy-encryption/ http://9to5mac.com/2015/06/02/tim-cook-privacy-encryption/
- deleted 11y ago[deleted]
- dodongogo 11y agoIt 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/sec/Security/SecItem.h 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, new items are created in the application's default access group. If I understand this correctly that would always make sure that when an existing entry is updated in an app, the 'hack' app would again be restricted in being able to access the entry's data. It could still clear the data, but wouldn't be able to access the contents. The paper seems to note this as well: > It turns out that all of [the apps] can be easily attacked except todo Cloud and Contacts Sync For Google Gmail, which delete their current keychain items and create new ones before updating their data. Note that this practice (deleting an existing item) is actually discouraged by Apple, which suggests to modify the item instead [9].
- justonepost 11y agoDoes this apply to iOS or just OSX?
- eridius 11y agoThe 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.
- dodongogo 11y agoAh, my mistake. Forgot that the access groups are scoped by bundle id on iOS. So yeah, this would only apply to OSX.
- tptacek 11y agoIt'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) application can contain helpers registered to the bundle IDs of other applications. The app installer will add those helpers to the ACLs of those other applications (but not to the ACLs of any Apple application). * A malicious OSX (but not iOS) application can subvert Safari extensions by installing itself and camping out on a Websockets port relied on by the extension. * A malicious iOS application can register itself as the URL handler for a URL scheme used by another application and intercept its messages. The headline news would have to be about iOS, because even though OSX does have a sandbox now, it's still not the expectation of anyone serious about security that the platform is airtight against malware. Compared to other things malware can likely do on OSX, these seem pretty benign. The Keychain and BID things are certainly bugs, but I can see why they aren't hair-on-fire priorities. Unfortunately, the iOS URL thing is I think extraordinarily well-known, because for many years URL schemes were practically the only interesting thing security consultants could assess about iOS apps, so limited were the IPC capabilities on the platform. There are surely plenty of apps that use URLs insecurely in the manner described by this paper, but it's a little unfair to suggest that this is a new platform weakness.
- giovannibajo1 11y agoIn iOS9, apps can now register to arbitrary http URLs, but that in fact requires the app to be correctly associated with the domain, which in turns requires a lengthy process (the domain must expose via HTTPS a json naming the bundle id, signed with the TLS private key). So I think they made it right for generic URLs while the custom URLs has been a little unfortunate from day 1, but it's hardly something new. Btw can anybody explain how association to arbitrary http URLs works in Android? Is there a similar validation, or can any app intercept any URL if it wishes so?
- dozy 11y ago