Hacker News Reader

Comment by blinkingled | Hacker News Reader

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.

View on HN

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.

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.

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

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.

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.

I don't know about the latest version of iOS, but your statement was certainly wrong just 2 years ago.

See https://www.usenix.org/system/files/conference/usenixsecurit... for details of how to write an app that bypasses App Store review but will have security holes that allow your app to access APIs at runtime with no notification that it was not supposed to have access to.

Yes, that was exactly my point. People keep repeating the iOS security being fundamentally better marketing mantra but it has been ordinary although the closed system helps it somewhat and they did seem to get the fingerprint security right. And I was referring to Android's permissions model when I said no you can't bypass it.

You may think it's "marketing mantra" if you're unaware of the technical differences. But compare, say, Apple's Secure Enclave with Host Card Emulation. Apple's design is just more secure. http://www.tomshardware.com/news/host-card-emulation-secure-...

I certainly don't understand characterizing iOS's security model as "ordinary." For example, it encrypts using a separate coprocessor running an entirely separate OS, that is protected against even an iOS kernel exploit. That's definitely not an ordinary design!

And on iOS, if your app does not receive permission to access your location or contacts or camera or Internet, there's no way to do that by using objc_msgSend or whatever.

On both platforms, these security policies are enforced at the process boundary, not by the runtime.

Reply on news.ycombinator.com