7 ms·

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 wa

by BooneJS 11y ago

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.

matthewmacleod 11y ago
I'm sure they can, and will probably start doing so.
K0nserv 11y ago
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
- uxp 11y ago
  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)
  - K0nserv 11y ago
    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
    - kenrikm 11y ago
      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/General/Conceptual/DevPedia-CocoaCore/Selector.html https://developer.apple.com/library/ios/documentation/Genera...
      - NateLawson 11y ago
        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-sessions/presentation/wang_tielei 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.
        jandrese 11y ago
        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.
NateLawson 11y ago
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. :-)

by BooneJS 11y ago

matthewmacleod 11y ago

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

K0nserv 11y ago

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

uxp 11y ago
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)
- K0nserv 11y ago
  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
  - kenrikm 11y ago
    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/General/Conceptual/DevPedia-CocoaCore/Selector.html https://developer.apple.com/library/ios/documentation/Genera...
    - NateLawson 11y ago
      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-sessions/presentation/wang_tielei 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.
      - jandrese 11y ago
        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.

NateLawson 11y ago

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