10 ms·

While Marcan has written in a very entertaining fashion, there is perhaps one application of this vulnerability that wasn't considered. If this can be reproduc

While Marcan has written in a very entertaining fashion, there is perhaps one application of this vulnerability that wasn't considered. If this can be reproduced on the iPhone, it can lead to 3rd party keyboards exfiltrating data. By default, keyboard app extensions are sandboxed away from their owning applications [0], but they may communicate with the app over this channel and leak data. It's not as easy as I describe because the app would have to be alive and scheduled on the same cluster, but it's within the realm of possibility. [0]: https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/CustomKeyboard.html https://developer.apple.com/library/archive/documentation/Ge...

gostsamo 5y ago
IPhones use A12/13/14 chip and the vulnerability is not confirmed there. Also, the post mentions that if you have two malware apps on your device, they can communicate in many other ways, so I'm not sure what's new here. Edit: fixed name of the chip.
- umanghere 5y ago
  iPhones do not use the A1 chip as of quite a few years ago. Besides, the M1 and the A12+ have significant microarchitectural similarities, to the point that the DTK used the A12Z. Furthermore, the keyboard app extension and the keyboard app are installed as a single package whose components are not supposed to communicate, hence why I brought this up.
  - gostsamo 5y ago
    The only 1 in the name of the chip is typo. The rest I'm still not sure if it is significant.
  - dfox 5y ago
    I believe that only significant difference between A14 and M1 (apart from package) is number of cores.
- Closi 5y ago
  iPad contains an m1 chip so that might be a similar better example.
- saagarjha 5y ago
  I just tested it on the A14 and it seemed to work there.
  - withinboredom 5y ago
    I wonder if it would have passed Apple's review process?
    - saagarjha 5y ago
      At this point I would hope that App Store ingestion would filter for this.
marcan_42 5y ago
I expect Apple to include checks for this in their App Store static analyzer, if they aren't already rejecting sysreg instructions, which mitigates the issue. Obviously JIT isn't allowed in the App Store, so this should be an effective strategy.
- rmst 5y ago
  How convenient for Apple. Now they finally have a good argument to keep forbidding JIT compilation and side-loading.
  - inetknght 5y ago
    > Now they finally have a good argument to keep forbidding JIT compilation and side-loading. The argument was there the entire time. Some people just buried their heads in the sand though.
  - mike_hearn 5y ago
    JITC is irrelevant actually. This is not an argument for blocking it. Firstly, no normal JITC will ever emit instructions that access undocumented system registers. Any JITC that comes from a known trusted source (and they're expensive to develop, so they basically all do) would be signed/whitelisted already and not be a threat anyway. So what about new/unrecognised programs or dylibs that request JITC access? Well, Apple already insist on creating many categories of disallowed thing in the app store that can't be detected via static analysis. For example, they disallow changing the behaviour of the app after it is released via downloaded data files, which is both very vague and impossible to enforce statically. So it doesn't fundamentally change the nature of things. But what if you insist on being able to specifically fix your own obscure CPU bugs via static analysis? Well, then XNU can just implement the following strategy: 1. If a dylib requests a JITC entitlement, and the Mach-O CD Hash is on a whitelist of "known legit" compilers, allow. 2. Otherwise, require pages to be W^X. So the JITC requests some writeable pages, fills them with code, and then requests the kernel to make the pages executable. At that point XNU suspends the process and scans the requested pages for illegal instruction sequences. The pages are hot in the cache anyway and the checks are simple, so it's no big deal. If the static checks pass, the page is flipped to be executable but not writeable and the app can proceed. Apple's ban on JITC has never really made much technical sense to me. It feels like a way to save costs on program static analysis investment and to try and force developers to use Apple's own languages and toolchains, with security being used as a fig leaf. It doesn't make malware harder to write but it definitely exposes them to possible legal hot water as it means competitors can't build first-party competitive web browsers for the platform. The only thing that saves them is their own high prices and refusal to try and grab high enough market share.
GuB-42 5y ago
This exact use case is touched on in the article. Here is the follow-up > However, since iOS apps distributed through the App Store are not allowed to build code at runtime (JIT), Apple can automatically scan them at submission time and reliably detect any attempts to exploit this vulnerability using static analysis (which they already use). We do not have further information on whether Apple is planning to deploy these checks (or whether they have already done so), but they are aware of the potential issue and it would be reasonable to expect they will. It is even possible that the existing automated analysis already rejects any attempts to use system registers directly.
- marcan_42 5y ago
  Full disclosure: I added this after the parent comment (and others) mentioned this case. :)
  - ncr100 5y ago
    Thanks - yeah that is a real flaw. Obfuscated malware where the malicious part is not obvious; it's distributed and requires a separate process/image. Curious to see if some smart Apple-ers can invent a fix for this, though it seems like "no way" given the vulnerability.
    - marcan_42 5y ago
      As I mentioned below and on the disclosure page, it's trivial for Apple to reliably detect this in apps submitted to the App Store and reject them, so I'm not worried. There's no such thing as "obfuscated" malware in the traditional sense on the App Store. You can obfuscate the code flow all you want, but all executable code has to be signed to run on iDevices. If you try to use this register, the instruction will be there for all to see. You can't use self-modifying code or packers on iOS.
Angostura 5y ago
Possibly, the article has been updated in the last couple of hours, but it now says: *What about iOS?* iOS is affected, like all other OSes. There are unique privacy implications to this vulnerability on iOS, as it could be used to bypass some of its stricter privacy protections. For example, keyboard apps are not allowed to access the internet, for privacy reasons. A malicious keyboard app could use this vulnerability to send text that the user types to another malicious app, which could then send it to the internet.
m3kw9 5y ago
There would be code signatures that can detect this use by apple?
- api 5y ago
  Detection is very hard if the developer employs very clever obfuscation. See: halting problem.
  - eloff 5y ago
    Only if detection requires solving the halting problem. It does not. You just look for certain instructions that normal code shouldn't use. JIT isn't allowed (which means all instructions the program uses can be checked statically), so it should be easy enough.
    - SheinhardtWigCo 5y ago
      Marcan said elsewhere in the thread that the executable section on ARM also includes constant pools, so if I understand correctly, you can hide instructions in there and make it intractable for a static analyzer to determine whether they are really instructions or just data. The real saving grace here is that iOS app binaries are submitted as LLVM IR instead of ARM machine code.
      - jshier 5y ago
        Only on watchOS is Bitcode required (to support the watch's 32-bit to 64-bit transition), on all other platforms it's optional and often turned off, as it makes a variety of things harder, like generating dSYMs for crash reporting.
        SheinhardtWigCo 5y ago
        Oh. Then I don't see how this can be reliably mitigated, other than patching LLVM to avoid writing the `msr s3_5_c15_c10_1` byte sequence in constant pools and then rejecting any binary that contains the byte sequence in an executable section. That seems difficult to get done before someone is able to submit a PoC malicious keyboard to the store, potentially turning this "joke" bug into a real problem. What am I missing?

gostsamo 5y ago

IPhones use A12/13/14 chip and the vulnerability is not confirmed there. Also, the post mentions that if you have two malware apps on your device, they can communicate in many other ways, so I'm not sure what's new here. Edit: fixed name of the chip.

umanghere 5y ago
iPhones do not use the A1 chip as of quite a few years ago. Besides, the M1 and the A12+ have significant microarchitectural similarities, to the point that the DTK used the A12Z. Furthermore, the keyboard app extension and the keyboard app are installed as a single package whose components are not supposed to communicate, hence why I brought this up.
- gostsamo 5y ago
  The only 1 in the name of the chip is typo. The rest I'm still not sure if it is significant.
- dfox 5y ago
  I believe that only significant difference between A14 and M1 (apart from package) is number of cores.
Closi 5y ago
iPad contains an m1 chip so that might be a similar better example.
saagarjha 5y ago
I just tested it on the A14 and it seemed to work there.
- withinboredom 5y ago
  I wonder if it would have passed Apple's review process?
  - saagarjha 5y ago
    At this point I would hope that App Store ingestion would filter for this.

marcan_42 5y ago

I expect Apple to include checks for this in their App Store static analyzer, if they aren't already rejecting sysreg instructions, which mitigates the issue. Obviously JIT isn't allowed in the App Store, so this should be an effective strategy.

rmst 5y ago
How convenient for Apple. Now they finally have a good argument to keep forbidding JIT compilation and side-loading.
- inetknght 5y ago
  > Now they finally have a good argument to keep forbidding JIT compilation and side-loading. The argument was there the entire time. Some people just buried their heads in the sand though.
- mike_hearn 5y ago
  JITC is irrelevant actually. This is not an argument for blocking it. Firstly, no normal JITC will ever emit instructions that access undocumented system registers. Any JITC that comes from a known trusted source (and they're expensive to develop, so they basically all do) would be signed/whitelisted already and not be a threat anyway. So what about new/unrecognised programs or dylibs that request JITC access? Well, Apple already insist on creating many categories of disallowed thing in the app store that can't be detected via static analysis. For example, they disallow changing the behaviour of the app after it is released via downloaded data files, which is both very vague and impossible to enforce statically. So it doesn't fundamentally change the nature of things. But what if you insist on being able to specifically fix your own obscure CPU bugs via static analysis? Well, then XNU can just implement the following strategy: 1. If a dylib requests a JITC entitlement, and the Mach-O CD Hash is on a whitelist of "known legit" compilers, allow. 2. Otherwise, require pages to be W^X. So the JITC requests some writeable pages, fills them with code, and then requests the kernel to make the pages executable. At that point XNU suspends the process and scans the requested pages for illegal instruction sequences. The pages are hot in the cache anyway and the checks are simple, so it's no big deal. If the static checks pass, the page is flipped to be executable but not writeable and the app can proceed. Apple's ban on JITC has never really made much technical sense to me. It feels like a way to save costs on program static analysis investment and to try and force developers to use Apple's own languages and toolchains, with security being used as a fig leaf. It doesn't make malware harder to write but it definitely exposes them to possible legal hot water as it means competitors can't build first-party competitive web browsers for the platform. The only thing that saves them is their own high prices and refusal to try and grab high enough market share.

GuB-42 5y ago

This exact use case is touched on in the article. Here is the follow-up > However, since iOS apps distributed through the App Store are not allowed to build code at runtime (JIT), Apple can automatically scan them at submission time and reliably detect any attempts to exploit this vulnerability using static analysis (which they already use). We do not have further information on whether Apple is planning to deploy these checks (or whether they have already done so), but they are aware of the potential issue and it would be reasonable to expect they will. It is even possible that the existing automated analysis already rejects any attempts to use system registers directly.

marcan_42 5y ago
Full disclosure: I added this after the parent comment (and others) mentioned this case. :)
- ncr100 5y ago
  Thanks - yeah that is a real flaw. Obfuscated malware where the malicious part is not obvious; it's distributed and requires a separate process/image. Curious to see if some smart Apple-ers can invent a fix for this, though it seems like "no way" given the vulnerability.
  - marcan_42 5y ago
    As I mentioned below and on the disclosure page, it's trivial for Apple to reliably detect this in apps submitted to the App Store and reject them, so I'm not worried. There's no such thing as "obfuscated" malware in the traditional sense on the App Store. You can obfuscate the code flow all you want, but all executable code has to be signed to run on iDevices. If you try to use this register, the instruction will be there for all to see. You can't use self-modifying code or packers on iOS.

Angostura 5y ago

Possibly, the article has been updated in the last couple of hours, but it now says: *What about iOS?* iOS is affected, like all other OSes. There are unique privacy implications to this vulnerability on iOS, as it could be used to bypass some of its stricter privacy protections. For example, keyboard apps are not allowed to access the internet, for privacy reasons. A malicious keyboard app could use this vulnerability to send text that the user types to another malicious app, which could then send it to the internet.

m3kw9 5y ago

There would be code signatures that can detect this use by apple?

api 5y ago
Detection is very hard if the developer employs very clever obfuscation. See: halting problem.
- eloff 5y ago
  Only if detection requires solving the halting problem. It does not. You just look for certain instructions that normal code shouldn't use. JIT isn't allowed (which means all instructions the program uses can be checked statically), so it should be easy enough.
  - SheinhardtWigCo 5y ago
    Marcan said elsewhere in the thread that the executable section on ARM also includes constant pools, so if I understand correctly, you can hide instructions in there and make it intractable for a static analyzer to determine whether they are really instructions or just data. The real saving grace here is that iOS app binaries are submitted as LLVM IR instead of ARM machine code.
    - jshier 5y ago
      Only on watchOS is Bitcode required (to support the watch's 32-bit to 64-bit transition), on all other platforms it's optional and often turned off, as it makes a variety of things harder, like generating dSYMs for crash reporting.
      - SheinhardtWigCo 5y ago
        Oh. Then I don't see how this can be reliably mitigated, other than patching LLVM to avoid writing the `msr s3_5_c15_c10_1` byte sequence in constant pools and then rejecting any binary that contains the byte sequence in an executable section. That seems difficult to get done before someone is able to submit a PoC malicious keyboard to the store, potentially turning this "joke" bug into a real problem. What am I missing?