Re: Scary Stuff!
On Jun 18, 2015, at 8:33 AM, Fritz Anderson fri...@manoverboard.org wrote: On Jun 17, 2015, at 4:46 PM, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: WHAT?!?! No! You gotta use ROT13! ;-P One pass? Reckless. I use eight. Sent to the list in error; I apologize.— F ___ 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
Re: Scary Stuff!
On Jun 17, 2015, at 4:46 PM, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: WHAT?!?! No! You gotta use ROT13! ;-P One pass? Reckless. I use eight. — F ___ 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
Re: Scary Stuff!
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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Scary Stuff!
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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Scary Stuff!
I’ve skimmed the paper; and it seems to me that there is no API/system-level solution possible. I’m not familiar with the Keychain API; owing to not having needed to use it, but it seems to me that a best practices approach can solve that issue: check that the keychain item’s properties (ACL most importantly) are what you expect before using it. However, the OS can’t know ahead-of-time what those ACLs should be; consequently it must fall to the app to provide that logic. Likewise, some containers are supposed to be shared; and others aren’t. The OS can’t know what that is; it must fall upon the App Store to validate that. An automated heuristics approach backed up by actual human validation of edge cases is probably the way to go for this: 1) Bundle identifiers that belong to the developer submitting the app automatically get passed. 2) Bundle identifiers that are known to be shared automatically get passed. 3) All others get human review. URL schemes should require registration with Apple; collisions should cause a store submission to fail. And lastly, if you have malware on your system; you are pretty much toast: despite all that we do to try to prevent it, no system of this level of complexity is perfect, and the good guys have to be right 100% of the time, while the bad guys only have to be right once in order for it to worm it’s way into the machine. On Jun 17, 2015, at 2:07 PM, Jens Alfke j...@mooseyard.com wrote: (“I know! I’ll write the passwords to a plist and XOR the bytes with a 32-bit secret number I hardcode in my app!”) WHAT?!?! No! You gotta use ROT13! ;-P ___ 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
Re: Scary Stuff!
On Jun 17, 2015, at 2:07 PM, Jens Alfke j...@mooseyard.com wrote: On Jun 17, 2015, at 1:17 PM, Doug Hill cocoa...@breaqz.com mailto:cocoa...@breaqz.com wrote: 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) Does it? I’m using Chrome on Mac OS and it uses the Keychain. (I just opened Keychain Access and verified that a password I’d added in Chrome this morning shows up there.) Annoyingly, though, it doesn’t recognize Keychain items created by Safari, which means I have to keep looking up passwords in Keychain Access the first time I visit a site in Chrome. From The Register article: 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.” Take this as you will from a Register article. It does sound like there are some best practices that would defeat some of these attacks — like making sure to always create new Keychain items instead of re-using existing ones. Also to show how hard it is to handle security issues, from the researchers’ paper: “For Google Gmail, which delete their current keychain items and create new ones before updating their data (sic). Note that this practice (deleting an existing item) is actually discouraged by Apple, which suggests to modify the item instead.” Even going by Apple’s suggestions it’s hard to get all this right. Doug ___ 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
Re: Scary Stuff!
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
Re: Scary Stuff!
On Jun 17, 2015, at 1:17 PM, Doug Hill cocoa...@breaqz.com wrote: 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) Does it? I’m using Chrome on Mac OS and it uses the Keychain. (I just opened Keychain Access and verified that a password I’d added in Chrome this morning shows up there.) Annoyingly, though, it doesn’t recognize Keychain items created by Safari, which means I have to keep looking up passwords in Keychain Access the first time I visit a site in Chrome. This is obviously it’s own set of security issues. Totally. It would be a bad idea for developers to respond to this research by creating their own secure storage. (“I know! I’ll write the passwords to a plist and XOR the bytes with a 32-bit secret number I hardcode in my app!”) It does sound like there are some best practices that would defeat some of these attacks — like making sure to always create new Keychain items instead of re-using existing ones. Hopefully people with the expertise will publish some. (Maybe there are some in the paper? I haven’t had time to finish it yet.) —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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Scary Stuff!
Hi, Has everyone seen this? http://www.theregister.co.uk/2015/06/17/apple_hosed_boffins_drop_0day_mac_ios_research_blitzkrieg/ http://www.theregister.co.uk/2015/06/17/apple_hosed_boffins_drop_0day_mac_ios_research_blitzkrieg/ Scares the living daylights out of me! Cheers Dave ___ 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
Re: Scary Stuff!
Wow - and not fixed in those 6 months. That does not sound good. ___ 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
Re: Scary Stuff!
On 17 Jun 2015, at 09:44, Torsten Curdt tcu...@vafer.org wrote: Wow - and not fixed in those 6 months. That does not sound good. That’s the scariest part! I thought that Apple might have made an announcement about it after the article appeared on The Register, but not seen anything yet! ___ 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
