5 ms·

New critical vulnerability in multiple high-privileged Android services

233 points by based2 8y ago

mettamage 8y ago
I skimmed it super quickly, though since no one is commenting, I'll just put this comment in there as an encouragement for others. I think the gist of it is as follows: 1. There is inter process communication. 2. For this there is shared memory of 64 bits. 3. Some processes are 32 bits and when they get this memory, they just use the lower 32 bits. Obviously I glossed over many details, but when a 32 bit process is just getting a part of memory and leaves the rest unchecked, that sounds like a good script for the start of a vulnerability (i.e. things being left unchecked).
- saagarjha 8y ago
  I also glanced at the article, so I have a couple more details (and a small correction; the memory itself is not being truncated, the size of the memory region is): 1. Binder allows sharing memory between processes. 2. The shared memory data structure includes a 64-bit size. 3. 32-bit processes attempt to mmap this and end up converting the 64-bit uint64_t size to a 32-bit size_t and mapping in the wrong amount of data. 4. MediaCasService, a HAL module that has access to the TEE for what is essentially DRM purposes, performs bounds checks in 64-bit and doesn’t use the shared memory at all. Thus, it provides what’s essentially arbitrary read/write. 5. Leaking the location of the stack and where libc is allows for a ROP chain (which is necessary because marking memory as executable is not possible). The author uses this to cobble together a PoC that dumps the QSEOS version.
  - trasz 8y ago
    Wait, a 32-bit size_t?
    - ChrisSD 8y ago
      In a 32-bit processes, yes. You would expect differently?
      - trasz 8y ago
        Ah, right, thank you. I got it mixed up with off_t.
wyldfire 8y ago
> Building the ROP chain itself is pretty straightforward. There are enough gadgets in libc to perform it and all the symbols are in libc as well, and we already have libc’s address. Can't we somehow escape/eliminate these ROP gadgets when building libc? BSD implemented a "RETGUARD" in clang for x86. IIRC, a lot of protection was offered by just tweaking register allocations. Don't/can't we have something similar for ARM?
- saagarjha 8y ago
  ARM 8.3’s pointer authentication might be what you’re looking for. Certain processors, notably Apple’s A12 chips, already implement this as a preventive measure against ROP.
  - wyldfire 8y ago
    It's not [what I'm looking for], but it's a great step forward, for sure. It should reduce/eliminate the buffer overflows/use-after-frees that could be used to kick off ROP, but AFAIK it doesn't eliminate the gadgets themselves.
    - saagarjha 8y ago
      The point of pointer authentication is to make it impossible to actually user gadgets because you would be hard-pressed to find a signed pointer that is necessary to actually jump to a arbitrary location, since you’d be missing the one that was handed out to you in the prologue had you gone the correct way through the function. I guess in a way it’s a type of CFI check. With regards to actually stopping buffer overflows or double frees, it’s not going to help much. But we have other mitigation techniques, such as stack cookies, to help in these cases.
      - wyldfire 8y ago
        Oh I confused pointer auth with the newer ARM MTE [1]. That (nearly) eliminates use-after-free/buffer-overflow. [1] https://community.arm.com/processors/b/blog/posts/arm-a-profile-architecture-2018-developments-armv85a https://community.arm.com/processors/b/blog/posts/arm-a-prof...
billpg 8y ago
Is this running-a-native-app scary or running-JS-in-a-browser scary?
- metalliqaz 8y ago
  From what I can tell, it could allow a malicious app to bad things, but the malicious app would already have to be installed.
kevin_b_er 8y ago
The other takeaway is that Digital Restrictions Management systems are the security lynchpin, as they run at a higher privilege level than the property owner is permitted. They are zealously guarded due to their nature, making it more difficult to understand the security threat digital restrictions management poses.
- saagarjha 8y ago
  The threat here is that DRM is done in the TEE so that it can’t be messed with by normal applications. This, however, opens up the rest of the TEE when bugs in the component are found.

233 points by based2 8y ago

I skimmed it super quickly, though since no one is commenting, I'll just put this comment in there as an encouragement for others. I think the gist of it is as follows: 1. There is inter process communication. 2. For this there is shared memory of 64 bits. 3. Some processes are 32 bits and when they get this memory, they just use the lower 32 bits. Obviously I glossed over many details, but when a 32 bit process is just getting a part of memory and leaves the rest unchecked, that sounds like a good script for the start of a vulnerability (i.e. things being left unchecked).

saagarjha 8y ago
I also glanced at the article, so I have a couple more details (and a small correction; the memory itself is not being truncated, the size of the memory region is): 1. Binder allows sharing memory between processes. 2. The shared memory data structure includes a 64-bit size. 3. 32-bit processes attempt to mmap this and end up converting the 64-bit uint64_t size to a 32-bit size_t and mapping in the wrong amount of data. 4. MediaCasService, a HAL module that has access to the TEE for what is essentially DRM purposes, performs bounds checks in 64-bit and doesn’t use the shared memory at all. Thus, it provides what’s essentially arbitrary read/write. 5. Leaking the location of the stack and where libc is allows for a ROP chain (which is necessary because marking memory as executable is not possible). The author uses this to cobble together a PoC that dumps the QSEOS version.
- trasz 8y ago
  Wait, a 32-bit size_t?
  - ChrisSD 8y ago
    In a 32-bit processes, yes. You would expect differently?
    - trasz 8y ago
      Ah, right, thank you. I got it mixed up with off_t.

wyldfire 8y ago

> Building the ROP chain itself is pretty straightforward. There are enough gadgets in libc to perform it and all the symbols are in libc as well, and we already have libc’s address. Can't we somehow escape/eliminate these ROP gadgets when building libc? BSD implemented a "RETGUARD" in clang for x86. IIRC, a lot of protection was offered by just tweaking register allocations. Don't/can't we have something similar for ARM?

saagarjha 8y ago
ARM 8.3’s pointer authentication might be what you’re looking for. Certain processors, notably Apple’s A12 chips, already implement this as a preventive measure against ROP.
- wyldfire 8y ago
  It's not [what I'm looking for], but it's a great step forward, for sure. It should reduce/eliminate the buffer overflows/use-after-frees that could be used to kick off ROP, but AFAIK it doesn't eliminate the gadgets themselves.
  - saagarjha 8y ago
    The point of pointer authentication is to make it impossible to actually user gadgets because you would be hard-pressed to find a signed pointer that is necessary to actually jump to a arbitrary location, since you’d be missing the one that was handed out to you in the prologue had you gone the correct way through the function. I guess in a way it’s a type of CFI check. With regards to actually stopping buffer overflows or double frees, it’s not going to help much. But we have other mitigation techniques, such as stack cookies, to help in these cases.
    - wyldfire 8y ago
      Oh I confused pointer auth with the newer ARM MTE [1]. That (nearly) eliminates use-after-free/buffer-overflow. [1] https://community.arm.com/processors/b/blog/posts/arm-a-profile-architecture-2018-developments-armv85a https://community.arm.com/processors/b/blog/posts/arm-a-prof...

billpg 8y ago

Is this running-a-native-app scary or running-JS-in-a-browser scary?

metalliqaz 8y ago
From what I can tell, it could allow a malicious app to bad things, but the malicious app would already have to be installed.

kevin_b_er 8y ago

The other takeaway is that Digital Restrictions Management systems are the security lynchpin, as they run at a higher privilege level than the property owner is permitted. They are zealously guarded due to their nature, making it more difficult to understand the security threat digital restrictions management poses.

saagarjha 8y ago
The threat here is that DRM is done in the TEE so that it can’t be messed with by normal applications. This, however, opens up the rest of the TEE when bugs in the component are found.