5 ms·

Java's access controls are trivial to bypass on Android. Neither the Android or iOS runtimes are there to enforce a security policy. You should read Apple's iO

Java's access controls are trivial to bypass on Android. Neither the Android or iOS runtimes are there to enforce a security policy. You should read Apple's iOS Security Whitepaper: http://www.apple.com/business/docs/iOS_Security_Guide.pdf http://www.apple.com/business/docs/iOS_Security_Guide.pdf See for example the data protection classes: a very thoughtful design, with no analog in Android, and that certainly could not have come about by "happenstance." Heck, Android doesn't even encrypt your data by default! That alone makes iOS "fundamentally more secure."

blinkingled 11y ago
> Java's access controls are trivial to bypass on Android. You keep repeating that but I am certain you don't understand what you are talking about. Go download the Android SDK, emulator and write an app that does that and post it on Github We will talk about it then. Also - I'll leave this here - http://www.macrumors.com/2015/10/19/apple-to-remove-hundreds-apps-youmi-sdk/ http://www.macrumors.com/2015/10/19/apple-to-remove-hundreds...
- millstone 11y ago
  > write an app that does that Here's a sample of how to invoke `Activity.savedDialogKeyFor`, which is private: Method privateMethod = Activity.class.getDeclaredMethod("savedDialogKeyFor", int.class); privateMethod.setAccessible(true); String result = (String)privateMethod.invoke(this, 42); System.out.println("Got result: " + result); Worked perfectly on Android Marshmallow emulator. As I said, it's trivial. > Also - I'll leave this here What's your point? There was no security exploit here, and no security policy can realistically prevent networked apps from sharing data like your email address. That falls to the review process. What's remarkable here is how little data this malware was actually able to capture. Certainly less than on Android, where users routinely grant excessive permissions, like giving Netflix access to your phone.
  - blinkingled 11y ago
    You're confusing accessing private methods with violating the Android permissions model. Two totally separate things. Edit: Also my larger point was the iOS security is not fundamentally better than anything else. The closed nature, restrictive policies etc. help but fundamentally it's nothing outstanding. It was a response to tptacek claiming opposite.
    - millstone 11y ago
      I am not confused. Please reread the thread. You asserted that iOS is "unfixable" because the ObjC runtime cannot prevent apps from using "private/internal calls that your app is not supposed to use," whereas "Android gets code access control for free with Java." But as I showed, Java access controls are easily bypassed, so they do not provide any security. This is by design: security is enforced at the process boundary, not by the runtime. My hope is that you now appreciate that neither the ObjC nor Android Java runtimes are a security risk, because they are not responsible for enforcing any security policy. > Also my larger point was the iOS security is not fundamentally better than anything else iOS security is fundamentally better. You can read the whitepaper to understand the ways: data protection classes, the Secure Enclave, and lots more. But here's a damning fact: iOS encrypts your data by default, Android does not. That by itself makes iOS fundamentally more secure.
      - blinkingled 11y ago
        You should really read this Usenix paper - https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_wang-updated-8-23-13.pdf https://www.usenix.org/system/files/conference/usenixsecurit... . What you are not understanding or ignoring is that iOS apps (over 250) that were App Store approved were able to retrieve personal user data including email addresses by reverse engineering the names of the private APIs and using message passing. Android sure has private APIs and you can access those but you're still restricted to the permissions you asked for. For example you need to declare android.permission.GET_ACCOUNTS permission to get the user's primary email. Not on iOS apparently where they rely on manual review to ensure you are not calling the Private API - which fails as can be seen in the Chinese AD SDK fiasco I posted. So no Android runtime isn't a security risk as much as iOS private APIs are - your app gets a broad set of permissions on iOS by default and you can do clever trickery to call private APIs to collect personal info and who knows what else without the user knowing. Android needs your app to ask for that permission first (and at runtime on M)- you aren't calling a private method on Android without declaring the necessary permission to get what you want without user interaction.
deleted 11y ago
[deleted]

blinkingled 11y ago

> Java's access controls are trivial to bypass on Android. You keep repeating that but I am certain you don't understand what you are talking about. Go download the Android SDK, emulator and write an app that does that and post it on Github We will talk about it then. Also - I'll leave this here - http://www.macrumors.com/2015/10/19/apple-to-remove-hundreds-apps-youmi-sdk/ http://www.macrumors.com/2015/10/19/apple-to-remove-hundreds...

millstone 11y ago
> write an app that does that Here's a sample of how to invoke `Activity.savedDialogKeyFor`, which is private: Method privateMethod = Activity.class.getDeclaredMethod("savedDialogKeyFor", int.class); privateMethod.setAccessible(true); String result = (String)privateMethod.invoke(this, 42); System.out.println("Got result: " + result); Worked perfectly on Android Marshmallow emulator. As I said, it's trivial. > Also - I'll leave this here What's your point? There was no security exploit here, and no security policy can realistically prevent networked apps from sharing data like your email address. That falls to the review process. What's remarkable here is how little data this malware was actually able to capture. Certainly less than on Android, where users routinely grant excessive permissions, like giving Netflix access to your phone.
- blinkingled 11y ago
  You're confusing accessing private methods with violating the Android permissions model. Two totally separate things. Edit: Also my larger point was the iOS security is not fundamentally better than anything else. The closed nature, restrictive policies etc. help but fundamentally it's nothing outstanding. It was a response to tptacek claiming opposite.
  - millstone 11y ago
    I am not confused. Please reread the thread. You asserted that iOS is "unfixable" because the ObjC runtime cannot prevent apps from using "private/internal calls that your app is not supposed to use," whereas "Android gets code access control for free with Java." But as I showed, Java access controls are easily bypassed, so they do not provide any security. This is by design: security is enforced at the process boundary, not by the runtime. My hope is that you now appreciate that neither the ObjC nor Android Java runtimes are a security risk, because they are not responsible for enforcing any security policy. > Also my larger point was the iOS security is not fundamentally better than anything else iOS security is fundamentally better. You can read the whitepaper to understand the ways: data protection classes, the Secure Enclave, and lots more. But here's a damning fact: iOS encrypts your data by default, Android does not. That by itself makes iOS fundamentally more secure.
    - blinkingled 11y ago
      You should really read this Usenix paper - https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_wang-updated-8-23-13.pdf https://www.usenix.org/system/files/conference/usenixsecurit... . What you are not understanding or ignoring is that iOS apps (over 250) that were App Store approved were able to retrieve personal user data including email addresses by reverse engineering the names of the private APIs and using message passing. Android sure has private APIs and you can access those but you're still restricted to the permissions you asked for. For example you need to declare android.permission.GET_ACCOUNTS permission to get the user's primary email. Not on iOS apparently where they rely on manual review to ensure you are not calling the Private API - which fails as can be seen in the Chinese AD SDK fiasco I posted. So no Android runtime isn't a security risk as much as iOS private APIs are - your app gets a broad set of permissions on iOS by default and you can do clever trickery to call private APIs to collect personal info and who knows what else without the user knowing. Android needs your app to ask for that permission first (and at runtime on M)- you aren't calling a private method on Android without declaring the necessary permission to get what you want without user interaction.

deleted 11y ago

[deleted]