7 ms·
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 h
by babesh 5y ago
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.
- saagarjha 5y agoIt’s pretty trivial to encode a backdoor into your app that would let you remotely call native code of your choice.
- yccs27 5y agoI guess this is the reason Apple restricts apps from executing downloaded code.
- saagarjha 5y agoThis 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.
- babesh 5y agoYeah, it wouldn't be too hard to write an interpreter. It is a lot like compiler class.
- worrycue 5y ago> 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?
- babesh 5y agoNo. Those static analysis tools don't catch everything. There are relatively well known and somewhat widespread tricks to avoid being caught by them.
- babesh 5y agoI 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.
- illusionofchaos 5y agoI 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.
- worrycue 5y agoCatching some is better than catching none. Apple will be evolving their analysis tools too as they go along.
- 5y ago
- pjmlp 5y agoThe 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.
- babesh 5y agoI wasn't clear. It is dynamically constructing an API call that Objective-C allows. The objc_msgSend stuff.
- pjmlp 5y agoWhich you can call directly from Swift.
- babesh 5y agoYou are right. https://steipete.com/posts/calling-super-at-runtime/ https://steipete.com/posts/calling-super-at-runtime/
- illusionofchaos 5y agoLook 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