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 mdcrawf...@gmail.com 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 <cocoa...@breaqz.com> 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 <j...@mooseyard.com> 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 (Cocoa-dev@lists.apple.com) > > 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 mdcrawf...@gmail.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
