3 ms·

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.

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.