Hacker News Reader

Comment by babesh | Hacker News Reader

Don’t update your apps till after Apple releases a patch. The first two are API calls that apps can make.

An exploit wishing to exploit these vulnerabilities has to be coded to make these calls. Most apps don’t dynamically construct arbitrary API calls. In fact, you can’t do that in Swift AFAIK. You have to drop to Objective-C or C to do that.

So most apps need to be updated to exploit the vulnerability. The only exceptions would be apps that are intentionally constructed to call arbitrary APIs or at least with arbitrary parameters. The first would be a violation of developer agreements but that hasn’t stopped people in the past. Also, these aren’t even private APIs. These are public APIs that got exploited due to not properly checking parameters/entitlements.

I wonder if Apple isn’t running static analysis tools right now to look for these vulnerabilities against all apps.

View on HN

> I wonder if Apple isn’t running static analysis tools right now to look for these vulnerabilities against all apps.

On a side note, this is one more reason Apple can cite for their App Store exclusivity. If there is a vulnerability in the OS exploitable by apps, and they can’t get a patch out in time, they can screen and prevent the download of such dangerous apps.

Not a popular position here I know. But I’m correct no?

No. Those static analysis tools don't catch everything. There are relatively well known and somewhat widespread tricks to avoid being caught by them.

I speculate that GameKit is basically abandonware by Apple. They even got rid of the app a few years ago.

There probably hasn't been hardening of it in years and the initial work was probably developed in haste.

This is systemic. Apple has a bad habit of abandoning software that isn't a priority. So, one shouldn't be surprised that Apple hasn't fixed these exploits. And I wonder if the author has fully mined GameKit for exploits yet. Perhaps there are more to be found.

The architecture of iOS and OSX isn't conducive to security AFAIK. It is more of an add-on as one can see instead of being architected in.

I haven't checked further, maybe authentication token can be used to gain access to Apple account and more data. Also one other method could used to write arbitrary data outside of an app sandbox, that might be useful for further exploitation.

Catching some is better than catching none. Apple will be evolving their analysis tools too as they go along.

> But I’m correct no?

You're not correct - Apple can still scan apps installed from elsewhere. With a user opt-in, Android can verify side-loaded apps - no App-store exclusivity required.

It’s pretty trivial to encode a backdoor into your app that would let you remotely call native code of your choice.

I guess this is the reason Apple restricts apps from executing downloaded code.

This is without downloading additional code. Reuse attacks such as ROP, or you could just embed an interpreter with the ability to alter native register state. It’s not hard to get Turing completeness into your app in a way that lets it call whatever it wants.

Yeah, it wouldn't be too hard to write an interpreter. It is a lot like compiler class.

The whole point of Swift is to be next generation Objective-C and C on Apple platforms, no need to drop down to other languages.

In fact, the prof of concepts shown in the article are all written in Swift.

I wasn't clear. It is dynamically constructing an API call that Objective-C allows. The objc_msgSend stuff.

Which you can call directly from Swift.

You are right.

https://steipete.com/posts/calling-super-at-runtime/

Look at the code of gamed exploit that I've uploaded to GitHub, the app is written in Swift and it calls Objective-C runtime functions from it

Reply on news.ycombinator.com