3 ms·
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
by 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 agoI 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.