I was a "Debug Meister" for Apple in the mid-90s. It was fascinating work but I applied for an internal transfer because I had the sense that my work would never be finished.
That is, we will never run out of bugs. It gets me down sometimes. Michael David Crawford, Consulting Software Engineer [email protected] http://www.warplife.com/mdc/ Available for Software Development in the Portland, Oregon Metropolitan Area. On Wed, Jun 17, 2015 at 1:17 PM, Doug Hill <[email protected]> wrote: > 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 protected]> 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 protected]) > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com > > This email sent to [email protected] _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
