Re: Scary Stuff!
Re: Scary Stuff!
- Subject: Re: Scary Stuff!
- From: Doug Hill <email@hidden>
- Date: Wed, 17 Jun 2015 13:17:39 -0700
This is indeed some scary stuff. The problem with apps creating a local web server for Web Socket support also seems particularly worrisome. I second Jens’ suggestion to read the paper because it will cause eyes to bug out.
For most of the security problems, you could rewrite your app to opt-out of the insecure APIs, system services, etc. and use your own implementation. (see Google Chrome not storing passwords in the Keychain anymore) This is obviously it’s own set of security issues. Do you want to implement your own secure password store and ensure you don’t introduce other security holes? Good luck with that.
The one feature that I don’t know anyway to opt-out yet still keep functionality is the custom URL scheme registration on iOS. This gets used for IPC to open files in another app. Any app could register the same custom URL scheme for another app without the knowledge of the user or the original app. Users would Open In one of their files, thinking it will go to the original app, which gets hijacked by the malicious app. I don’t know if there’s even a way to know if another app has hijacked your scheme. Think about opening files with confidential/financial data and they suddenly get sent to a malicious app.
I’m looking forward to fixes and/or workarounds soon.
Doug Hill
> On Jun 17, 2015, at 12:44 PM, Jens Alfke <email@hidden> wrote:
>
> As usual, don’t put too much weight into the bite-size digests from the press, especially the Register, which has a track record of sensationalism. Unfortunately the actual truth is fairly bad. I recommend reading the paper:
>
> https://drive.google.com/file/d/0BxxXk1d3yyuZOFlsdkNMSGswSGs/view <https://drive.google.com/file/d/0BxxXk1d3yyuZOFlsdkNMSGswSGs/view>
>
> Haven’t gotten all the way through it, but the security problems in the OS seem to be not about the fundamentals — the integrity of sandboxes and the Keychain are OK — but some slipshod security at the API level and in the ways these components get used. The two OS X attacks I’ve read about are:
>
> 1. Keychain ACLs control which apps are allowed to read which Keychain secrets. But it’s possible for a malicious app to create a blank Keychain password item for a secret it knows some other app will store there (like a login password), and give both itself and the real app access. Then the true app will store the secret in the existing Keychain item, which is readable by the malware so it can get the password from it.
>
> 2. Sandboxed apps are given private directories named after their bundle IDs. The Mac App Store submission process verifies that an app’s bundle ID is a valid one that’s registered to the developer … but it doesn’t verify the bundle IDs of embedded executables like plugins, which get their own sandboxes. So a malicious app can include a plugin with the bundle ID registered to a real app, and its plugin will be able to share the sandbox with the real app and read/write its data.
>
> (I may have gotten details wrong. Don’t quote me on this, read the paper yourself.)
>
> Both of these are pretty bad. I’m very disappointed that Apple didn’t address these during the six months’ advance notice that the security researchers gave before they went public.
>
> —Jens
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden