34 ms·

I had a pretty detailed discussion with iOS engineers at a WWDC a couple of years back. It was a somewhat frustrating conversation, mostly because of how badly

by itripn 13y ago

I had a pretty detailed discussion with iOS engineers at a WWDC a couple of years back. It was a somewhat frustrating conversation, mostly because of how badly I wanted true user generated Framework support, but also because the engineers had decent reasons for the existing state of things. Primarily that Frameworks (in their fullest expression) are dynamically loaded. Apple has made a decision that allowing 3rd parties to dynamically load code (outside of Apple certified frameworks) is a security issue on a mobile platform in particular. I don't have a solid counter argument, although there are certainly some technical constraints they could put in place to help mitigate the risk. Anyway, agree with your essay in general. But I also understand how we got here. Cheers

mikeash 13y ago
We're already dynamically loading one chunk of third-party code: the app. Why are third-party frameworks any different? Presumably they would be subject to the exact same code signing and approval processes as the main app.
- 0x0 13y ago
  Then you could probably replace a dylib inside one app, with a dylib from another. If Apple codesigns all dylibs in apps, you could just submit a silly little app with a malicious dylib, grab the signed dylib from the appstore later and play games with third party apps.
  - mikeash 13y ago
    The code signature for an app extends to the frameworks it contains. You can't just replace them and still have a valid signature.
    - quesera 13y ago
      The code signature is on the multiple architecture binary, thereby including any statically linked object files, right? If Apple were to add dynamic libs, they would presumably be separate binary files, with their own signatures. This could raise the concern noted by 0x0.
      - teacup50 13y ago
        > If Apple were to add dynamic libs, they would presumably be separate binary files, with their own signatures. No. That's not how it works on Mac OS X today, where bundled shared libraries are supported.
        quesera 13y ago
        That's right, thanks. Separate binary files have individual hashes, which are included in the package manifest file. The manifest is then signed, so a single signature covers all hashed files in the manifest. Curiously though, in all of the MAS apps I've checked, bundled dylibs are explicitly not hashed in the manifest. This is the developers choice, but perhaps a default?
teacup50 13y ago
Assuming that there really do still existing technical constraints, these aren't insurmountable problems. They're not even difficult problems. Apple has more than enough cash on hand to spend the engineering time necessary to solve them and still have money left over for a campus Beer Bash. Note that on Mac OS X when using code signing, including when distributing via the Mac App Store, dynamic libraries are supported.
cromwellian 13y ago
Besides security issues, I'm wonder if another motivation is anti-DRM circumventing, working around App Store restrictions, etc.
wsc981 13y ago
I don't get this. Based on my experience, even without framework support, it should be pretty easy to write some code in iOS that loads some code in from a remote location, just by using NSBundle functionality. After all, NSBundle files may include runnable code, in addition to resources. I'm not sure if such apps would get past Apple's tooling / testers though, when submitted to the store. Is it harder for Apple to check if remote code loading functionality (and other potential security issues) is included in frameworks compared to bundles?
- mikeash 13y ago
  Apple blocks loading any new executable code after your process starts. Fundamentally, the OS prohibits normal processes from marking any pages as executable. You can load the data fine, but you can't execute it. NSBundle won't help you. The problem being proposed here is that the ability to have embedded frameworks would somehow weaken this strong protection against loading new code at runtime, although I don't really see how personally.
binarycrusader 13y ago
If anything, in my mind, not using shared libraries is a security issue. For example, if every application links to a static version of some image loading library, then all of the applications must be patched if there is a vulnerability in that library. Whereas if they all share the same copy, you patch the library, and they all get fixed. I'm aware that model works better when the same vendor is providing all of the binaries, but there are cases where it's also appropriate for general ISVs.
- CoolGuySteve 13y ago
  It's a two sided coin, if you update a dynamically loaded library that subtly breaks backwards compatibility, you end up with apps that mysteriously stop working because of some other update in the system. Really, it's up to the app maintainer to update their program, and if it has a vulnerability, in theory the sandbox will prevent it from doing damage to others.
  - binarycrusader 13y ago
    If someone updates a library incompatibility, they deserve what they get. That's why shared libraries have versioning. In the mobile space, it would be even more beneficial if platform holders and ISVs actually followed this; the memory and space usage savings could be substantial.
    - binarycrusader 13y ago
      I'm uncertain why someone would downvote my comment above, but shared library versioning is a real thing, and it is a best practice: http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries... https://www.usenix.org/legacy/publications/library/proceedings/als00/2000papers/papers/full_papers/browndavid/browndavid_html/ https://www.usenix.org/legacy/publications/library/proceedin... Linux distributions heavily depend on this for the GCC runtime libraries (such as libgcc_s); it's how they provide backwards compatibility. Many operating system distributors also rely on symbol versioning for their shared libraries as well so they can compatibly evolve interfaces for consumers. So my original point stands, if someone incompatibly updates a shared library without accounting for versioning, they're doing it wrong.
CoolGuySteve 13y ago
It's the app developer's responsibility to update and QA their program. If Apple allowed dynamically loaded libraries across the OS, then subtle issues in an App update could cause that one update to break seemingly unrelated apps. Windows developers call this DLL hell, and even with manifests and SxS, Microsoft still doesn't have an attractive solution to the problem. Meanwhile, from a security standpoint, the sandbox should prevent apps from interfering with the files of each other and the OS. And from a performance perspective, the few kilobytes (even entire megabytes!) of duplicated code segments is inconsequential on a phone with 1GB of RAM and very few context switches across apps.
- skue 13y ago
  No, you are conflating two separate concepts. Just because a framework is dynamic doesn't mean it has to be shared. MacOS X provides all the benefits of dynamic frameworks that Landon outlines, but third party frameworks are almost always bundled within each app (and on iOS they would certainly be required to be).
  - itripn 13y ago
    I am not actually conflating them at all. However, Frameworks as implemented on iOS are at present dynamically loaded. As I said, there are technical ways to address that particular issue, some of which bring iOS Frameworks more in parity with OS X.

by itripn 13y ago

mikeash 13y ago

We're already dynamically loading one chunk of third-party code: the app. Why are third-party frameworks any different? Presumably they would be subject to the exact same code signing and approval processes as the main app.

0x0 13y ago
Then you could probably replace a dylib inside one app, with a dylib from another. If Apple codesigns all dylibs in apps, you could just submit a silly little app with a malicious dylib, grab the signed dylib from the appstore later and play games with third party apps.
- mikeash 13y ago
  The code signature for an app extends to the frameworks it contains. You can't just replace them and still have a valid signature.
  - quesera 13y ago
    The code signature is on the multiple architecture binary, thereby including any statically linked object files, right? If Apple were to add dynamic libs, they would presumably be separate binary files, with their own signatures. This could raise the concern noted by 0x0.
    - teacup50 13y ago
      > If Apple were to add dynamic libs, they would presumably be separate binary files, with their own signatures. No. That's not how it works on Mac OS X today, where bundled shared libraries are supported.
      - quesera 13y ago
        That's right, thanks. Separate binary files have individual hashes, which are included in the package manifest file. The manifest is then signed, so a single signature covers all hashed files in the manifest. Curiously though, in all of the MAS apps I've checked, bundled dylibs are explicitly not hashed in the manifest. This is the developers choice, but perhaps a default?

teacup50 13y ago

Assuming that there really do still existing technical constraints, these aren't insurmountable problems. They're not even difficult problems. Apple has more than enough cash on hand to spend the engineering time necessary to solve them and still have money left over for a campus Beer Bash. Note that on Mac OS X when using code signing, including when distributing via the Mac App Store, dynamic libraries are supported.

cromwellian 13y ago

Besides security issues, I'm wonder if another motivation is anti-DRM circumventing, working around App Store restrictions, etc.

wsc981 13y ago

I don't get this. Based on my experience, even without framework support, it should be pretty easy to write some code in iOS that loads some code in from a remote location, just by using NSBundle functionality. After all, NSBundle files may include runnable code, in addition to resources. I'm not sure if such apps would get past Apple's tooling / testers though, when submitted to the store. Is it harder for Apple to check if remote code loading functionality (and other potential security issues) is included in frameworks compared to bundles?

mikeash 13y ago
Apple blocks loading any new executable code after your process starts. Fundamentally, the OS prohibits normal processes from marking any pages as executable. You can load the data fine, but you can't execute it. NSBundle won't help you. The problem being proposed here is that the ability to have embedded frameworks would somehow weaken this strong protection against loading new code at runtime, although I don't really see how personally.

binarycrusader 13y ago

If anything, in my mind, not using shared libraries is a security issue. For example, if every application links to a static version of some image loading library, then all of the applications must be patched if there is a vulnerability in that library. Whereas if they all share the same copy, you patch the library, and they all get fixed. I'm aware that model works better when the same vendor is providing all of the binaries, but there are cases where it's also appropriate for general ISVs.

CoolGuySteve 13y ago
It's a two sided coin, if you update a dynamically loaded library that subtly breaks backwards compatibility, you end up with apps that mysteriously stop working because of some other update in the system. Really, it's up to the app maintainer to update their program, and if it has a vulnerability, in theory the sandbox will prevent it from doing damage to others.
- binarycrusader 13y ago
  If someone updates a library incompatibility, they deserve what they get. That's why shared libraries have versioning. In the mobile space, it would be even more beneficial if platform holders and ISVs actually followed this; the memory and space usage savings could be substantial.
  - binarycrusader 13y ago
    I'm uncertain why someone would downvote my comment above, but shared library versioning is a real thing, and it is a best practice: http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries... https://www.usenix.org/legacy/publications/library/proceedings/als00/2000papers/papers/full_papers/browndavid/browndavid_html/ https://www.usenix.org/legacy/publications/library/proceedin... Linux distributions heavily depend on this for the GCC runtime libraries (such as libgcc_s); it's how they provide backwards compatibility. Many operating system distributors also rely on symbol versioning for their shared libraries as well so they can compatibly evolve interfaces for consumers. So my original point stands, if someone incompatibly updates a shared library without accounting for versioning, they're doing it wrong.

CoolGuySteve 13y ago

It's the app developer's responsibility to update and QA their program. If Apple allowed dynamically loaded libraries across the OS, then subtle issues in an App update could cause that one update to break seemingly unrelated apps. Windows developers call this DLL hell, and even with manifests and SxS, Microsoft still doesn't have an attractive solution to the problem. Meanwhile, from a security standpoint, the sandbox should prevent apps from interfering with the files of each other and the OS. And from a performance perspective, the few kilobytes (even entire megabytes!) of duplicated code segments is inconsequential on a phone with 1GB of RAM and very few context switches across apps.

skue 13y ago
No, you are conflating two separate concepts. Just because a framework is dynamic doesn't mean it has to be shared. MacOS X provides all the benefits of dynamic frameworks that Landon outlines, but third party frameworks are almost always bundled within each app (and on iOS they would certainly be required to be).
- itripn 13y ago
  I am not actually conflating them at all. However, Frameworks as implemented on iOS are at present dynamically loaded. As I said, there are technical ways to address that particular issue, some of which bring iOS Frameworks more in parity with OS X.