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

http://www.theregister.co.uk/2015/06/17/apple_hosed_boffins_drop_0day_mac_ios_research_blitzkrieg/

by moe • 11 years ago

501 139 11 years ago

theregister.co.uk

therealmarv2• 11 years ago

So 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• 11 years ago

exactly....

coldtea• 11 years 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• 11 years ago

They 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• 11 years ago

How do you know they was aware if they didn't "not even communicating"?

Oletros2• 11 years ago

According to the article, they were aware

lgrebe• 11 years ago

FTA: "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• 11 years ago

I'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• 11 years ago

Don't forget 'goto fail'.

soylentcola• 11 years ago

I'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.

userbinator2• 11 years ago

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.

DennisP2• 11 years ago

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

ajross• 11 years ago

It also works if the target has installed an exploitable app, or one that can be trojaned via an included component. That sort of thing has happened in the past even from "reputable" software vendors (c.f. Lenovo/Superfish or the Sony rootkit), so pretending that it can't happen on App Store seems naive to me.

No, this isn't a remote root, but it's pretty severe and not something that should be downplayed with italics.

yAnonymous• 11 years ago

Apple's stance on security is "fix it when there's an exploit" rather than "fix it when it's broken".

madaxe_again• 11 years ago

According 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.

StavrosK• 11 years ago

"Boffins"? Isn't that rather dismissive, as in "oh, look at what those crazy boffins cooked up now!"?

dghf• 11 years ago

It's the standard Reg term for scientists and academics.

zelos• 11 years ago

It's tongue-in-cheek. The Register's style is basically a joke on British tabloid styles.

jahnu• 11 years ago

I don't think it's a joke. I think they actively approve of tabloid style journalism.

See Orlowski's rants on climate change for example.

cremno• 11 years ago

That would also explain the blitzkrieg part.

huxley2• 11 years ago

Boffin just means someone that has an esoteric or difficult-to-master skill.

Nexxxeh• 11 years ago

It'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-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.

koenigdavidmj• 11 years ago

And don't forget any music industry articles, which spell out the name of the Recording Industry Ass. of America.

0x0• 11 years ago

Anyone 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?

therealmarv2• 11 years ago

Chromium security issues are not public visible. At least as long as the security issue remains.

anon1385• 11 years ago

That 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

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

andor• 11 years 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• 11 years ago

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

gpvos2• 11 years 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.

draugadrotten• 11 years 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• 11 years 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.

pilsetnieks2• 11 years 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_latte2• 11 years ago

This would only show if you've been exploited already

What would indicate a compromise?

MaysonL• 11 years ago

I'm curious: do you have any idea why after running this command would security start asking for password for various keychains?

bshep• 11 years ago

The results are pretty unwieldly if you have a lot of passwords so I used the following snippet to sift through the crud

  cat results.txt | grep -A 20 'applications' |grep \[0-9\]: | grep -v entry | grep -v description | cut -d\  -f14- |  sort | uniq

I made a couple of assumptions so YMMV:

  - up to 10 apps in the ACL ( the max I saw in mine was 7 )

  - the word 'entry' or 'decription' was no present in the app name

peterhil• 11 years ago

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)) <blob>="[^"]*"|^\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'

Someone2• 11 years 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• 11 years 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.

eridius8• 11 years 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.

gchp• 11 years ago

Well, 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• 11 years ago

You 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• 11 years ago

In 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

drtse4• 11 years ago

From 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.

jdc05892• 11 years ago

was 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

* disclaimer, that egrep regex is shit.

c0wb0yc0d3r• 11 years ago

Can you skip the whole writing to file bit, and pipe straight to egrep?

SlashmanX• 11 years ago

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

PhantomGremlin• 11 years ago

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.

jusio• 11 years ago

Oh God. After reading the paper I wouldn't expect a fix from Apple anytime soon :(

watmough• 11 years ago

Right, 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.

ikeboy2• 11 years ago

I wonder if the new "Rootless" feature prevents this, and if it was developed because of this.

smackfu2• 11 years ago

Rootless is more about securing the OS files and processes from malware.

ikeboy2• 11 years ago

Isn't this similar? Rootless is strengthening the sandbox against malware.

Anyone on the new Mac version want to test this?

w8rbt2• 11 years ago

The 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• 11 years ago

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”.

reitanqild• 11 years ago

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.)

opcvx2• 11 years ago

Where should the state be kept, on a server?

w8rbt2• 11 years ago

No where electronically. A simple word or phrase in the user's mind would do.

Rather than being stored for later retrieval, complex passwords could be generated on-the-fly (when needed) using this word/phrase as input combined with other input such as URLs, hostnames, service names, etc.

taeric• 11 years ago

The fundamental problem with this idea is that the computer has to store your password somewhere, for it to be able to check it. Now, these particular passwords could be kept only on the server, but they are still kept. In a file. On a computer.

Your comment comes across as somewhat silly and akin to saying that the problem is we have to transmit the passwords (or some derivative data) across the internet to do business with someone. Yes... that is a facet of the problem. It is also a facet of how work gets done.

MagerValp2• 11 years ago

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

kinofcain2• 11 years ago

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).

MagerValp2• 11 years ago

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.

wahsd• 11 years ago

Bravo, 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.

josteink3• 11 years ago

Once 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• 11 years 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.

josteink3• 11 years ago

Yes, 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.

sigzero• 11 years ago

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

userbinator2• 11 years ago

Not strange if you grasp the fact that malware is just a program that has elevated access

I would define malware more simply as a program that does something the user doesn't want.

eridius8• 11 years ago

For me it was strange how can Apple market their system as virus-free. Now that's ridiculous.

Not really. I've been using Macs for as long as I can remember (I'm 30), and in that entire time, I've only ever actually seen 2 pieces of malware myself (I've heard of others but never actually encountered them). One of them was the rather benign Merry Xmas Hypercard trojan from way back, which doesn't actually harm your computer, all it does is search for other hypercard stacks on your computer to infect, and if you open an infected stack on December 25th it will play sound and wish you a Merry Xmas. The other one was one of those Adware apps, I forget its precise name, and I didn't actually even see that, I talked with someone else on the phone who had it and walked them through the instructions at https://support.apple.com/en-us/HT203987 for removing it.

And just to note, the latter one isn't even a virus, because it's not self-replicating (the former one technically is, because it infects other stacks on the same computer, but it was pretty darn benign and did not rely on an OS security flaw to operate).

So yeah, there exists malware for the Mac, and there's more of it now than there ever has been in the past, but it's like a completely different universe from Windows malware. You pretty much have to go out of your way to hit this on the Mac.

As an aside, the first widely-spread Mac malware I ever heard of was spread via a pirated copy of iWork '09 being distributed on BitTorrent. Someone had altered the DMG to include the virus before uploading it. It was kind of funny hearing about people being infected because you knew the only way they could have done that was by trying to pirate iWork '09 (this was the only distribution vector). And even that apparently doesn't count as a "major" security threat because the Wikipedia page[1] for Mac Defender, which is dated to May 2011, describes Mac Defender as "the first major malware threat to the Macintosh platform", even though it wasn't even a virus it was just a trojan (and FWIW it didn't even require antivirus software to remove, Apple rolled out an automatic fix themselves, although it did take them a few weeks to do so).

[1] https://en.wikipedia.org/wiki/Mac_Defender

CPLX• 11 years ago

In fairness, for most of the 2000's in my experience at least -- which included defacto admin duties for a decent size office fill of Macs -- dealing with malware and viruses really just wasn't much of a problem to worry about.

By contrast, it seemed like owning a Wintel machine pretty much guaranteed you'd have issues unless you were utterly ruthless and/or didn't have any layman users browsing the internet to worry about.

Has that in fact changed since? I am no longer as familiar with the Windows side of things as I used to be, but I do know from experience that there's a very solid reason why this stereotype took root in the first place.

Aloisius• 11 years ago

Does anyone remember the I'm a PC ads, where macs were magically "secure", couldn't get viruses or hacked or anything?

Well in 2006 when those ads were first being shown, XP was still the newest version of Windows and it had no privilege separation. As viruses that patched MBR sectors or system DLLs were extremely common, MacOS X was in fact "magically" (inherently) more secure since that vector of attack on a Mac would require a password prompt to elevate the program's privileges.

From then to this day, Mac viruses have been effectively non-existent in the wild. There have been some trojans and worms, but they can't rightfully be classified as viruses (no infection of other files).

josteink3• 11 years ago

Well in 2006 when those ads were first being shown, XP was still the newest version of Windows and it had no privilege separation

That's probably false. Windows introduced this feature in Windows 2000 (from 1999) and you could define a "normal" user and a "power" user. Only when you needed to install something would you run as the power-user.

This all worked inside the same desktop session.

That maybe only 1% of the users (the "paranoid" ones) used it, doesn't mean it wasn't there.

FerrisDr• 11 years ago

I agree. I guess the guys down here in the greyed out area are more after some kind of justice. It's more the arrogance of apple that people want to give back to apple.

jpmoral• 11 years ago

Okay, 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• 11 years ago

Don'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• 11 years ago

The 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• 11 years ago

they'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/

dodongogo2• 11 years ago

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, 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].

justonepost2• 11 years ago

Does this apply to iOS or just OSX?

eridius8• 11 years ago

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.

dodongogo2• 11 years ago

Ah, my mistake. Forgot that the access groups are scoped by bundle id on iOS. So yeah, this would only apply to OSX.

tptacek5• 11 years ago

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) 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• 11 years ago

In 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• 11 years ago

In Android it's all been rolled into the Intent/IPC system since day 1. Apps are composed of Activities, and Activities can defined Intent filters. Intent filters describe what the Activity can handle, including but not limited to URLs.

Through this system, any app can register for any url (IIRC you can filter by scheme, host, and/or path). When a url is invoked, the system asks the user which app should handle it if there are several that can. You can also set a default app for the given url, etc - the whole system, though very flexible, has been widely criticized as having mediocre UX (though IMO it mostly works just fine).

In Android M (unreleased), they've added a similar feature as in iOS 9 whereby you can ensure that URLs you define and own are always handled by your app. Essentially you host a json file at your domain, served over https, that specifies the SHA256 fingerprint of your app's signing cert. Your app defines the url filter similar to before and the system makes sure that you match the fingerprint.

Android being Android, you can still tweak the default handling of intents even if apps do this, but it's pretty hidden.

justonepost2• 11 years ago

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 skeptical as to their chops given the general disorganization of their paper and their over hyping of the scheme issue which is pretty basic / well known. And, in fact, it's not that hard to authenticate an incoming scheme on iOS via app prefix. Just have to dig in the docs a bit.

tptacek5• 11 years ago

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

eridius8• 11 years ago

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 other app, not to send sensitive info to that app.

tptacek5• 11 years ago

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.

patsplat• 11 years ago

https://blog.agilebits.com/2015/06/17/1password-inter-proces...

This particular attack is worrisome because it doesn’t require “admin” or “root” access, unlike other attacks that depend on the presence of malicious software on the system.

It's a weakness.

tptacek5• 11 years ago

It clearly is a weakness on OSX (apparently much less so on iOS). The issue is, it's not a new weakness.

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

Related Stories