[blinkingled]

> in a lot of practical ways better than that of Android.

Umm no - the update situation is better on iOS but fundamentally iOS has bigger problems - https://twit.tv/shows/security-now/episodes/532?autostart=fa... . That problem is unfixable easily due to the way ObjC works. Android gets code access control for free with Java. There have always been Jailbreaks for most iOS versions and it's not like they haven't had other security issues. The ability to fix them quickly is certainly an advantage but there is nothing in iOS that is fundamentally more secure than anything else on the market.

Frankly I think Apple's security is a combination of happenstance and restrictive policies - I don't think they care (yet) about the processes, infrastructure and people required to do what Google and Microsoft do. (No offense to the good security people at Apple - this isn't about them, this is about having organization wide security focus like MS needed to turn around Windows.)

[tptacek]

I don't understand what your argument is. Untethered jailbreaks on iOS are worth gigantic amounts of money because they are not easy to come by.

[blinkingled]

But they have existed for every version of iOS none the less. The relative difficulty may quite well be due to other reasons - closed source, locked down hardware etc. Says nothing about software security.

[mahyarm]

Rooting your phone when your not allowed is so common in android it might as well be a non-event.

[tim333]

Some recent figures: (http://betanews.com/2015/06/26/android-is-the-biggest-target...)

>"There was significant growth in Android malware, which currently consists of 97 percent of all mobile malware developed. In 2014 alone, there were 1,268 known families of Android malware, which is an increase of 464 from 2013 and 1,030 from 2012", it said.

Apple’s iOS, on the other hand, went through last year basically unscratched. The report said that there were just four iOS targeted attacks in 2014, and the majority of those were designed to infiltrate jailbroken devices.

[blinkingled]

I would not read too much into 'reports' by companies trying to sell you security products.

If you want to talk impacts - both iOS and Android have been similarly impacted - big name apps getting into App Store that were compiled by hacked XCode, Ad SDKs using forbidden APIs etc. Likewise most Android malware is due to rooting and side loading apps from questionable sources.

[tim333]

So Android getting about 100x as much malware as iOS is not significant? That's from all reporting I've seen, not just that one. Just because iOS has problems too doesn't make the numbers the same.

[blinkingled]

It would be significant if the statement was "There are 100x more infected Android phones than iOS phones."

Remember that Android is a lot of things - there are Nexus phones, there are OHA OEM phones (majority of them), there are Chinese no name phones that use open source Android etc. So if most Chinese people use AOSP build provided by their phone maker and they all sideload apps and get infected - that's different. Even considering all this nobody is making the above statement.

Just having malware written for an OS means nothing. It only suggest that it is targeted more due to market share. If people jailbreak their iPhones and install random apps from untrusted sources there is hardly anything Apple's security can do to prevent it. Same goes for Android. Nothing in that reflects the security of the underlying platform.

[lern_too_spel]

Orders of magnitude more iOS users have been infected by malware (via XcodeGhost) than Google-flavored Android users, despite the latter platform having multiple times more users. The reports you're pointing to list malware in Chinese app stores on non-Google-flavored devices.

[protomyth]

"That problem is unfixable easily due to the way ObjC works"

Can you explain that?

[blinkingled]

You should listen to the podcast for details but the gist of it is that "The Objective-C model of object-oriented programming is based on message passing to object instances. In Objective-C one does not call a method; one sends a message." So let's say you have an app that uses a runtime. The runtime in turn may use private/internal calls that your app is not supposed to use. Well there is no reliable way to prevent it because as long as you can construct a message and know the string/name of the target you can call it and there is no easy way for static analysis to detect such behavior.

Some apps were exploiting this to get a list of running apps and things like that.

[tptacek]

This is extraordinarily silly. In modern systems security, real security boundaries aren't enforced at the language level. No amount of ObjC message-sending trickery is going to change your UID.

[blinkingled]

Yeah, I have been around long enough to know you can't change to UID zero by message passing. That is just preposterous to assume. I was talking at the Runtime level - I even cited an app that was calling a runtime method to get list of running apps. Essentially they have no reliable runtime permission model - they rely on obscurity and static scanning to prevent you from passing message to some receivers that they don't want you to.

I would have thought you will research it a bit before asserting silliness - but oh well.

[ryanpetrich]

Apple is slowly migrating a massive amount of system features out of private frameworks and into background daemons protected by entitlements or privacy prompts. The end goal is that all sensitive data or hardware features are completely inaccessible from inside the sandbox, neither by private API, nor IOKit, nor syscall, nor direct filesystem access.

Retrieving the application list is a particularly poor example as there used to be a public API that did exactly that: CFPreferencesCopyApplicationList

[millstone]

The runtime is trivial to bypass on Android as well: Reflection, NDK, etc. It's not intended to enforce a security policy.

The "receivers that they don't want you to" on iOS is not about security, but correctness, binary compatibility, and app store guidelines. iOS's security model is not defeated by bypassing the ObjC runtime.

[blinkingled]

No it isn't - if your app did not ask for say a permission to connect to Internet or get a list of apps - there is no way to do that using reflection or NDK or whatever.

[millstone]

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 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]

> 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...

[millstone]

> 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]

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]

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]

You should really read this Usenix paper - 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.