5 ms·

Preventing it in a technical way is far from easy: If your app calls public API X, which as part of its implementation calls private API Y, your compiler only n

by euyyn 10y ago

Preventing it in a technical way is far from easy: If your app calls public API X, which as part of its implementation calls private API Y, your compiler only needs a declaration of Y to output the function call / ObjC message send. Nothing in the language prevents it, and the code is executed natively unlike Java.

tluyben2 10y ago
They control the software and the hardware though: seems possible to allow a specific region of memory (aka their public API) to call a specific region of memory (private API) and segfault for all the rest that does that?
- jahewson 10y ago
  Many private APIs are methods on objects which are part of public APIs, so there's no "region" of memory which cleanly corresponds to private APIs.
  - tluyben2 10y ago
    But they can theoretically create that as they own the entire chain; dev env, tools, OS, software, hardware (CPU included). I know it is not currently the case, sure, but they can do it was my point.
    - euyyn 10y ago
      They "own" a compiler, but not all of them. Say they implement the scheme you mention in clang and the LLVM linker, so the function bodies of their public APIs end up placed in that privileged region of memory, and those of their private APIs end up in the restricted region. Nothing prevents gcc from producing object files that tell the linker "this user function is part of Apple's public APIs". And nothing prevents people from using a different linker anyway, one that would put private API body functions out of the restricted region of memory. The only real way to achieve that would be to move all their frameworks to the kernel, which would be all sorts of problematic.
      - Dylan16807 10y ago
        > Say they implement the scheme you mention in clang and the LLVM linker, so the function bodies of their public APIs end up placed in that privileged region of memory, and those of their private APIs end up in the restricted region. Agreed that this design is fundamentally flawed, but that's because the coder is providing the implementations of private code. Providing that is Apple's job. Put privileged code into a dynamically-linked library that Apple provides. Only code in that block of memory can call private APIs. Pretty straightforward to implement, and requires nothing fancy from the kernel. Of course this only works if you can prevent the attacker from corrupting memory.
        euyyn 10y ago
        I don't know if iOS does randomization of loading addresses, but if so, that'd be a disadvantage. And well, in any case they need to maintain compatibility with current apps for who knows how many years.
        Dylan16807 10y ago
        > I don't know if iOS does randomization of loading addresses, but if so, that'd be a disadvantage. Such a scheme wouldn't stop ASLR. The loader just needs to tell the verification code where it put the privileged libraries. > And well, in any case they need to maintain compatibility with current apps for who knows how many years. Do they? I think Apple could easily order everyone to switch over to a more secure compiler with a one year deadline.
- eridius 10y ago
  At best all they could do is change literally every single private function call everywhere to inspect the return address and see if that return address is in a system framework or is in the app image. But this would be huge overhead, a real pain in the ass, and also not even reliable, because all you have to do is pick a public function, figure out the address of the `ret` instruction, push your $pc onto the stack, and then call the private function passing the address of that `ret` instruction as the return address. The private function will see that this address is in a system framework, and so will work, and then it will return, passing control to that `ret` instruction which immediately returns back to your real caller function. So no, there's no way for Apple to technologically make it impossible to call private functions. The only actual solution there would be to completely rewrite the OS such that literally every call into a framework that an app makes actually goes over IPC (so that way apps can't even attempt to invoke private functions since they won't be linked into the app), but that would probably be crazy slow which is why nobody does that.

by euyyn 10y ago

tluyben2 10y ago

They control the software and the hardware though: seems possible to allow a specific region of memory (aka their public API) to call a specific region of memory (private API) and segfault for all the rest that does that?

jahewson 10y ago
Many private APIs are methods on objects which are part of public APIs, so there's no "region" of memory which cleanly corresponds to private APIs.
- tluyben2 10y ago
  But they can theoretically create that as they own the entire chain; dev env, tools, OS, software, hardware (CPU included). I know it is not currently the case, sure, but they can do it was my point.
  - euyyn 10y ago
    They "own" a compiler, but not all of them. Say they implement the scheme you mention in clang and the LLVM linker, so the function bodies of their public APIs end up placed in that privileged region of memory, and those of their private APIs end up in the restricted region. Nothing prevents gcc from producing object files that tell the linker "this user function is part of Apple's public APIs". And nothing prevents people from using a different linker anyway, one that would put private API body functions out of the restricted region of memory. The only real way to achieve that would be to move all their frameworks to the kernel, which would be all sorts of problematic.
    - Dylan16807 10y ago
      > Say they implement the scheme you mention in clang and the LLVM linker, so the function bodies of their public APIs end up placed in that privileged region of memory, and those of their private APIs end up in the restricted region. Agreed that this design is fundamentally flawed, but that's because the coder is providing the implementations of private code. Providing that is Apple's job. Put privileged code into a dynamically-linked library that Apple provides. Only code in that block of memory can call private APIs. Pretty straightforward to implement, and requires nothing fancy from the kernel. Of course this only works if you can prevent the attacker from corrupting memory.
      - euyyn 10y ago
        I don't know if iOS does randomization of loading addresses, but if so, that'd be a disadvantage. And well, in any case they need to maintain compatibility with current apps for who knows how many years.
        Dylan16807 10y ago
        > I don't know if iOS does randomization of loading addresses, but if so, that'd be a disadvantage. Such a scheme wouldn't stop ASLR. The loader just needs to tell the verification code where it put the privileged libraries. > And well, in any case they need to maintain compatibility with current apps for who knows how many years. Do they? I think Apple could easily order everyone to switch over to a more secure compiler with a one year deadline.
eridius 10y ago
At best all they could do is change literally every single private function call everywhere to inspect the return address and see if that return address is in a system framework or is in the app image. But this would be huge overhead, a real pain in the ass, and also not even reliable, because all you have to do is pick a public function, figure out the address of the `ret` instruction, push your $pc onto the stack, and then call the private function passing the address of that `ret` instruction as the return address. The private function will see that this address is in a system framework, and so will work, and then it will return, passing control to that `ret` instruction which immediately returns back to your real caller function. So no, there's no way for Apple to technologically make it impossible to call private functions. The only actual solution there would be to completely rewrite the OS such that literally every call into a framework that an app makes actually goes over IPC (so that way apps can't even attempt to invoke private functions since they won't be linked into the app), but that would probably be crazy slow which is why nobody does that.