Hacker News Reader

Private API isn't a security mechanism. Apple attempts to detect it, and reject apps that use it, purely to be friendlier to their users. Private API usage makes apps more likely to break with OS updates, and Apple doesn't want apps breaking.

So while Apple is motivated to catch this stuff to an extent, they aren't that motivated, and they may well be perfectly happy with the current level of sophistication.

Does anyone know why they aren't access protected? It seems like poor security to just hope that apps don't call these functions.

Didn't I just answer that? It's not security at all, and not meant to be.

Not really. If there are apps using these disallowed APIs, why would Apple care about breaking them if they removed access? In every case where an app is discovered using the APIs, they remove them from the app store. App compatibility is not the issue.

There's still no clear reason why Apple choose to enforce the security via app reviews, rather than the system call returning 'permission denied' to apps without the right security level.

Compatibility is absolutely why they try to catch these things in review. Apple doesn't want a situation where iOS 10 results in 90% of the top apps breaking, because users will blame Apple and their reputation will suffer.

But it is not a security thing at all.

Either way, why not just deny access? It guarantees that apps won't break in this way, removes some pain from the process of approving apps (they don't need to check for this anymore), and improves privacy / security as a side effect!

Deny access how, exactly? Strictly enforcing privilege separation within the same process is basically impossible without running lesser-privileged code in a VM or something basically equivalent.

I could see an object-capability based scheme working well.

Apple is probably in the unique position to actually implement such a system successfully, controlling the hardware, os, and even language choice.

Sure, if Apple banned Objective-C/C/C++ and assembly code (never mind that most games are written in C++), set up a new system where all developers had to upload Swift IR, removed all unsafe APIs (at a sometimes very high performance cost), and audited all the rest of the gazillions of APIs for memory unsafety in the face of deliberate misuse, then they could implement an in-process object capability system that had only a few thousand vulnerabilities, similar to WebKit.

Or they could continue with the current sandboxing system where security- and privacy-critical functionality is performed out of process, and plug the remaining leaks, of which there aren't that many.

Isn't this what entitlements do? I honestly have no idea how they work - perhaps blog material? :)

Entitlements regulate what out-of-process facilities you're allowed to access. (For example, entitlements let you access certain parts of the filesystem, or the network, or access location services.) Private APIs are regular boring in-process classes, methods, and functions which just aren't documented by Apple and aren't part of their public interface. You call them in the same way as you do a public API: by jumping to the function, or invoking objc_msgSend to send a message to an object, all within your process.

They do deny access, and they usually seem to try to do it in a backwards-compatible way. For example, if you try to get the list of installed apps by brute-forcing URL schemas, they return "no more entries" after 50 calls now.

This way your code and most legit code that is not trying thousands of URLs works, but apps are trying to do this fail but don't crash.

Because enforcing restrictions in code makes the kernel and runtime more complex.

But that's its job!

open() would be a much simpler syscall if it didn't bother to enforce access controls. The code would be a lot easier to maintain too...

I'm not sure I understand your argument. Because there is already some complexity in the kernel, we should be fine with adding more complexity to it?

It could use many of the existing access control methods already in the kernel. No extra kernel complexity required.

e.g. the advertising ID could be stored in a file with appropriate permissions. All the API needs to do is open the file and read it out.

It is not the runtime's job. It is the kernel's job, but the whole point of private API is that they're within the same process and don't require a syscall to invoke. Calls which require kernel involvement that you're not supposed to be able to call already have access control mechanisms so you can't call them.

Well yes, I meant it's the kernel's job. If the information is already in-process, then there's no access control at all and an app could just read it directly, rather than calling a private API.

I think we're talking at cross-purposes. My original question was why Apple don't restrict this restricted information. It appears we both agree that putting it behind an access control (like a syscall) would prevent this.

Right. It's confusing in a discussion about private API in general, because private API is pretty much by definition calls with no access control which are merely undocumented. Thus saying that Apple should be more clever about prohibiting private API calls is weird. But if it's just one particular call that needs better enforcement, yeah, they should do that. And it will involve promoting it beyond "private API."

> My original question was why Apple don't restrict this restricted information.

Because Apple wants to use this information, but they don't want anybody else to use this information.

If Apple requires security permission to get at the information, then they hose themselves as well.

You're both right. It's the kernel's job to ultimately enforce this policy, and calling private APIs should only be a compatibility problem, not a security risk.

I believe the current sandbox design makes it more complex to promote system interfaces to require individual access control. It doesn't provide the fine-grained access, so more work is needed to separate code with the granularity that sandbox policies can control it.

This does happen over time (e.g. UDID in iOS 8).

In what way is the sandbox not fine grained? I thought the whole idea with entitlements was that access to individual facilities could be controlled separately.

I believe now that apps can get the level of info shown in the article it will become a user privacy issue--making it quite closely linked to security.

If so, then Apple will add restrictions to which apps are able to make these calls, by moving them out of process and adding actual security checks. That's how everything that's actually security-critical (calls that manipulate other processes, filesystem access, hardware access, etc.) already works.

If there are any security implications to making a private API call then this implies that Apple's sandboxing system is broken. If so then the solution is to fix the sandbox. Better detection of private API usage might be good for them, but is neither necessary nor sufficient nor particularly useful for security.

I agree that enforcement is the best way to go here. Hopefully they will improve the granularity of sandbox control to make detecting private APIs purely a compatibility issue.

Some of these APIs are protected, and Apple keeps adding more to this list over time. For example, reading the UDID (hardware serial number) was blocked in iOS 8 and you need an entitlement to call this API. Since the list of entitlements is covered by Apple's code signature, ordinary apps from the App Store can't use them.

http://stackoverflow.com/a/27686125

The reason they don't just do this for every API is due to the sandbox design, which makes this cumbersome.

The use of entitlements to protect APIs is a matter of moving them out of process. This is a trend that has been going on for a long time, especially since the development of XPC in iOS 5.

The trend took big steps in iOS 6, when Apple created a mechanism for remote views, and moved things like sending SMS and email out of process, in addition to the mechanism for determining what process gets what touches (backboardd).

As you mentioned, MobileGestalt was another step in this direction, when Apple blocked access to the MAC address and UDID.

iOS was not originally engineered with this focus of security and sandboxing in mind. For example, CVE-2015-5880 (accessing contents of screen from anywhere prior to iOS 9) existed because the screen framebuffer was needed for QuartzCore to function, and Apple didn't take the time to re-engineer how things work.

The number of things you can still do from the sandbox is mind boggling, and Apple is aware of it, they just don't have the time to re-engineer everything.

Ironically new iOS updates tend to break older apps anyways.

toucharcade.com/2015/09/23/bioshock-removal-2k-support-response/

It's kind of an arms race. In the early days of iOS app development, developers would just not call the private APIs during the review period and hide them in an easter egg or enable them from the client checking with the server to see if the setting had been flipped to start using them. Ever since Apple started actually scanning the binaries developers have had to go to greater lengths to obfuscate the usage, but still give users the most powerful features.

Some of the things developed during the arms race have become best practices, though. If you are an iOS game developer and you release a game update without the ability to adjust the game substantially from the server side, you are really in trouble. It takes another long review period from Apple to change anything, so best practice is to control the functionality from the server where if it makes the game too difficult for the users or something it can be adjusted without suffering the Apple review delay.

> I'm actually very surprised this hasn't happened years ago.

It has happened years ago. About a year ago I left a company that was doing this for at least the last two or three years. Their motivations were strictly a technical workaround to get functionality that Apple didn't present to a public API, not to nefariously gather user info, but the technique is the same, and not particularly difficult to figure out.

Probably a good five years ago Apple rejected an app of mine for use of a private API (this was about the time their static analysis was implemented). Another company that sold a buttload of copies of their app had to have used the same API, and their app came out a little bit before mine. Could be Apple just missed it, but I suspect the company in question was doing something similar. (They made millions, I languished in obscurity, but I'm not bitter. <g>)

And those are just the ones I directly know about, or strongly suspect. I'm sure there are/were plenty more.

> I'm actually very surprised this hasn't happened years ago.

It has, and very early on Apple didn't check for their usage so developers started using class-dump results to look for interesting private/undocumented APIs.

Things went south when Apple started checking and rejecting applications which did that: https://www.cocoanetics.com/2009/11/forbidden-fruit-apple-ap...

The youmi stuff is creepy, but generally speaking it's more a question of there being no guarantee about these API's stability or continuity, so the application may break between even minor OS updates, which is undesirable.

What's so magical about Obj-C's runtime that this cannot be detected by Apple? If a third-party can scan for them, why can't Apple? If you're going to have a walled garden, by all means please ensure the walls can't be scaled or dug under.

I'm sure they can, and will probably start doing so.

AFAIK the combination of NSSelectorFromString and NSClassFromString would allow you to build and make calls from obfuscated strings during runtime. Since Objective-C uses message passing this is non trivial to catch. Compared to C were you must explicitly reference symbols that are easy to automatically check for detecting the use of third party APIs is more difficult.

I am not sure if you have to explicitly link against certain frameworks/dylibs though, someone with more knowledge feel free to correct me

The article touches on how to dynamically link into a framework/dylib at runtime with dlopen(3) and dlsym(3) to resolve it's symbols address space.

I've always wondered why Apple doesn't run all apps against a "debug" build of iOS that asserts that the caller of private APIs is itself internal/private to Apple, but instead relies on something akin to grepping the output of strings(1)

This seems like a good approach, but you can still get around it by detecting apple reviews and not doing anything with private APIs during them

It's quite trivial to setup a method that implements "NSSelectorFromString" [1] etc.. and have it read from a Json payload send from a server. It's very hard for Apple to check for that unless they have active monitoring on apps after the review process.

[1] https://developer.apple.com/library/ios/documentation/Genera...

Right. Any runtime behavior can be altered by observed state from outside the phone.

There's even a paper on intentionally inserting security flaws into your code and then exploiting them from your own server to change execution patterns:

https://www.usenix.org/conference/usenixsecurity13/technical...

Ultimately, you need to enforce access control instead of just trying to detect problems a priori. Apple's sandbox is a great start to that, and I expect they'll keep improving it to block apps like these.

The state doesn't even have to be from outside the phone. You could have an internal timer that kicks off 2 weeks after you've submitted to the App Store (to allow for unexpected delays) and switches on the evil behavior.

We don't know why these apps got through in particular. However, I do think we have a unique vantage point by being outside any particular app store.

We scan code on both iOS and Android, identifying libraries and patterns of behavior. OpenSSL, for example, is the same code, regardless of platform, but the versions of it may vary depending on packaging and porting. We found one guy who had compiled OpenSSL for Android and was distributing binaries from github. Not the safest way to get your software.

As a third-party, you can move quickly and correlate info across app stores. But I also think we've developed a pretty unique code analysis engine that neither Apple nor Google has. :-)

dlopen() can be used to call a C function by a string name.

More ambitious programmers can scan executable regions of memory for the instruction stream of the target function and call the address directly without any help from symbolic names at all.

Correct. Even easier, they can store a hash of the symbol name and walk the dyld cache until they find a match. No dlsym required.

The runtime isn't as straightforward as SourceDNA makes it seem.

I didn't say the function would be in a dynamic library, although you're right that this would work if it was.

A statically-linked function would have to be referenced directly in the executable somewhere.

> They could move as much "private" functionality as possible outside of Objective-C objects entirely, which requires that you know the C function name and makes it obvious when you've linked to it.

https://stackoverflow.com/questions/6530701/is-the-function-...

I wonder if it's possible to for the ObjC runtime to randomly obfuscate a processes' "private" selectors on startup, and rewrite ObjC invocations within system frameworks dynamically, to make private API usage harder.

Like what ASLR does for memory addresses, but for selectors.