6 ms·

Does anyone know why they aren't access protected? It seems like poor security to just hope that apps don't call these functions.

mikeash 11y ago
Didn't I just answer that? It's not security at all, and not meant to be.
- joosters 11y ago
  Not really. If there are apps using these disallowed APIs, why would Apple care about breaking them if they removed access? In every case where an app is discovered using the APIs, they remove them from the app store. App compatibility is not the issue. There's still no clear reason why Apple choose to enforce the security via app reviews, rather than the system call returning 'permission denied' to apps without the right security level.
  - mikeash 11y ago
    Compatibility is absolutely why they try to catch these things in review. Apple doesn't want a situation where iOS 10 results in 90% of the top apps breaking, because users will blame Apple and their reputation will suffer. But it is not a security thing at all.
    - furyg3 11y ago
      Either way, why not just deny access? It guarantees that apps won't break in this way, removes some pain from the process of approving apps (they don't need to check for this anymore), and improves privacy / security as a side effect!
      - mikeash 11y ago
        Deny access how, exactly? Strictly enforcing privilege separation within the same process is basically impossible without running lesser-privileged code in a VM or something basically equivalent.
        muaddirac 11y ago
        I could see an object-capability based scheme working well. Apple is probably in the unique position to actually implement such a system successfully, controlling the hardware, os, and even language choice.
        comex 11y ago
        Sure, if Apple banned Objective-C/C/C++ and assembly code (never mind that most games are written in C++), set up a new system where all developers had to upload Swift IR, removed all unsafe APIs (at a sometimes very high performance cost), and audited all the rest of the gazillions of APIs for memory unsafety in the face of deliberate misuse, then they could implement an in-process object capability system that had only a few thousand vulnerabilities, similar to WebKit. Or they could continue with the current sandboxing system where security- and privacy-critical functionality is performed out of process, and plug the remaining leaks, of which there aren't that many.
        MagerValp 11y ago
        Isn't this what entitlements do? I honestly have no idea how they work - perhaps blog material? :)
        mikeash 11y ago
        Entitlements regulate what out-of-process facilities you're allowed to access. (For example, entitlements let you access certain parts of the filesystem, or the network, or access location services.) Private APIs are regular boring in-process classes, methods, and functions which just aren't documented by Apple and aren't part of their public interface. You call them in the same way as you do a public API: by jumping to the function, or invoking objc_msgSend to send a message to an object, all within your process.
      - NateLawson 11y ago
        They do deny access, and they usually seem to try to do it in a backwards-compatible way. For example, if you try to get the list of installed apps by brute-forcing URL schemas, they return "no more entries" after 50 calls now. This way your code and most legit code that is not trying thousands of URLs works, but apps are trying to do this fail but don't crash.
  - tptacek 11y ago
    Because enforcing restrictions in code makes the kernel and runtime more complex.
    - joosters 11y ago
      But that's its job! open() would be a much simpler syscall if it didn't bother to enforce access controls. The code would be a lot easier to maintain too...
      - tptacek 11y ago
        I'm not sure I understand your argument. Because there is already some complexity in the kernel, we should be fine with adding more complexity to it?
        joosters 11y ago
        It could use many of the existing access control methods already in the kernel. No extra kernel complexity required. e.g. the advertising ID could be stored in a file with appropriate permissions. All the API needs to do is open the file and read it out.
      - mikeash 11y ago
        It is not the runtime's job. It is the kernel's job, but the whole point of private API is that they're within the same process and don't require a syscall to invoke. Calls which require kernel involvement that you're not supposed to be able to call already have access control mechanisms so you can't call them.
        joosters 11y ago
        Well yes, I meant it's the kernel's job. If the information is already in-process, then there's no access control at all and an app could just read it directly, rather than calling a private API. I think we're talking at cross-purposes. My original question was why Apple don't restrict this restricted information. It appears we both agree that putting it behind an access control (like a syscall) would prevent this.
- josho 11y ago
  I believe now that apps can get the level of info shown in the article it will become a user privacy issue--making it quite closely linked to security.
  - mikeash 11y ago
    If so, then Apple will add restrictions to which apps are able to make these calls, by moving them out of process and adding actual security checks. That's how everything that's actually security-critical (calls that manipulate other processes, filesystem access, hardware access, etc.) already works. If there are any security implications to making a private API call then this implies that Apple's sandboxing system is broken. If so then the solution is to fix the sandbox. Better detection of private API usage might be good for them, but is neither necessary nor sufficient nor particularly useful for security.
    - NateLawson 11y ago
      I agree that enforcement is the best way to go here. Hopefully they will improve the granularity of sandbox control to make detecting private APIs purely a compatibility issue.
NateLawson 11y ago
Some of these APIs are protected, and Apple keeps adding more to this list over time. For example, reading the UDID (hardware serial number) was blocked in iOS 8 and you need an entitlement to call this API. Since the list of entitlements is covered by Apple's code signature, ordinary apps from the App Store can't use them. http://stackoverflow.com/a/27686125 http://stackoverflow.com/a/27686125 The reason they don't just do this for every API is due to the sandbox design, which makes this cumbersome.
- conradev 11y ago
  The use of entitlements to protect APIs is a matter of moving them out of process. This is a trend that has been going on for a long time, especially since the development of XPC in iOS 5. The trend took big steps in iOS 6, when Apple created a mechanism for remote views, and moved things like sending SMS and email out of process, in addition to the mechanism for determining what process gets what touches (backboardd). As you mentioned, MobileGestalt was another step in this direction, when Apple blocked access to the MAC address and UDID. iOS was not originally engineered with this focus of security and sandboxing in mind. For example, CVE-2015-5880 (accessing contents of screen from anywhere prior to iOS 9) existed because the screen framebuffer was needed for QuartzCore to function, and Apple didn't take the time to re-engineer how things work. The number of things you can still do from the sandbox is mind boggling, and Apple is aware of it, they just don't have the time to re-engineer everything.

mikeash 11y ago

Didn't I just answer that? It's not security at all, and not meant to be.

joosters 11y ago
Not really. If there are apps using these disallowed APIs, why would Apple care about breaking them if they removed access? In every case where an app is discovered using the APIs, they remove them from the app store. App compatibility is not the issue. There's still no clear reason why Apple choose to enforce the security via app reviews, rather than the system call returning 'permission denied' to apps without the right security level.
- mikeash 11y ago
  Compatibility is absolutely why they try to catch these things in review. Apple doesn't want a situation where iOS 10 results in 90% of the top apps breaking, because users will blame Apple and their reputation will suffer. But it is not a security thing at all.
  - furyg3 11y ago
    Either way, why not just deny access? It guarantees that apps won't break in this way, removes some pain from the process of approving apps (they don't need to check for this anymore), and improves privacy / security as a side effect!
    - mikeash 11y ago
      Deny access how, exactly? Strictly enforcing privilege separation within the same process is basically impossible without running lesser-privileged code in a VM or something basically equivalent.
      - muaddirac 11y ago
        I could see an object-capability based scheme working well. Apple is probably in the unique position to actually implement such a system successfully, controlling the hardware, os, and even language choice.
        comex 11y ago
        Sure, if Apple banned Objective-C/C/C++ and assembly code (never mind that most games are written in C++), set up a new system where all developers had to upload Swift IR, removed all unsafe APIs (at a sometimes very high performance cost), and audited all the rest of the gazillions of APIs for memory unsafety in the face of deliberate misuse, then they could implement an in-process object capability system that had only a few thousand vulnerabilities, similar to WebKit. Or they could continue with the current sandboxing system where security- and privacy-critical functionality is performed out of process, and plug the remaining leaks, of which there aren't that many.
      - MagerValp 11y ago
        Isn't this what entitlements do? I honestly have no idea how they work - perhaps blog material? :)
        mikeash 11y ago
        Entitlements regulate what out-of-process facilities you're allowed to access. (For example, entitlements let you access certain parts of the filesystem, or the network, or access location services.) Private APIs are regular boring in-process classes, methods, and functions which just aren't documented by Apple and aren't part of their public interface. You call them in the same way as you do a public API: by jumping to the function, or invoking objc_msgSend to send a message to an object, all within your process.
    - NateLawson 11y ago
      They do deny access, and they usually seem to try to do it in a backwards-compatible way. For example, if you try to get the list of installed apps by brute-forcing URL schemas, they return "no more entries" after 50 calls now. This way your code and most legit code that is not trying thousands of URLs works, but apps are trying to do this fail but don't crash.
- tptacek 11y ago
  Because enforcing restrictions in code makes the kernel and runtime more complex.
  - joosters 11y ago
    But that's its job! open() would be a much simpler syscall if it didn't bother to enforce access controls. The code would be a lot easier to maintain too...
    - tptacek 11y ago
      I'm not sure I understand your argument. Because there is already some complexity in the kernel, we should be fine with adding more complexity to it?
      - joosters 11y ago
        It could use many of the existing access control methods already in the kernel. No extra kernel complexity required. e.g. the advertising ID could be stored in a file with appropriate permissions. All the API needs to do is open the file and read it out.
    - mikeash 11y ago
      It is not the runtime's job. It is the kernel's job, but the whole point of private API is that they're within the same process and don't require a syscall to invoke. Calls which require kernel involvement that you're not supposed to be able to call already have access control mechanisms so you can't call them.
      - joosters 11y ago
        Well yes, I meant it's the kernel's job. If the information is already in-process, then there's no access control at all and an app could just read it directly, rather than calling a private API. I think we're talking at cross-purposes. My original question was why Apple don't restrict this restricted information. It appears we both agree that putting it behind an access control (like a syscall) would prevent this.
josho 11y ago
I believe now that apps can get the level of info shown in the article it will become a user privacy issue--making it quite closely linked to security.
- mikeash 11y ago
  If so, then Apple will add restrictions to which apps are able to make these calls, by moving them out of process and adding actual security checks. That's how everything that's actually security-critical (calls that manipulate other processes, filesystem access, hardware access, etc.) already works. If there are any security implications to making a private API call then this implies that Apple's sandboxing system is broken. If so then the solution is to fix the sandbox. Better detection of private API usage might be good for them, but is neither necessary nor sufficient nor particularly useful for security.
  - NateLawson 11y ago
    I agree that enforcement is the best way to go here. Hopefully they will improve the granularity of sandbox control to make detecting private APIs purely a compatibility issue.

NateLawson 11y ago

Some of these APIs are protected, and Apple keeps adding more to this list over time. For example, reading the UDID (hardware serial number) was blocked in iOS 8 and you need an entitlement to call this API. Since the list of entitlements is covered by Apple's code signature, ordinary apps from the App Store can't use them. http://stackoverflow.com/a/27686125 http://stackoverflow.com/a/27686125 The reason they don't just do this for every API is due to the sandbox design, which makes this cumbersome.

conradev 11y ago
The use of entitlements to protect APIs is a matter of moving them out of process. This is a trend that has been going on for a long time, especially since the development of XPC in iOS 5. The trend took big steps in iOS 6, when Apple created a mechanism for remote views, and moved things like sending SMS and email out of process, in addition to the mechanism for determining what process gets what touches (backboardd). As you mentioned, MobileGestalt was another step in this direction, when Apple blocked access to the MAC address and UDID. iOS was not originally engineered with this focus of security and sandboxing in mind. For example, CVE-2015-5880 (accessing contents of screen from anywhere prior to iOS 9) existed because the screen framebuffer was needed for QuartzCore to function, and Apple didn't take the time to re-engineer how things work. The number of things you can still do from the sandbox is mind boggling, and Apple is aware of it, they just don't have the time to re-engineer everything.