
New critical vulnerability in multiple high-privileged Android services - based2
https://blog.zimperium.com/cve-2018-9411-new-critical-vulnerability-multiple-high-privileged-android-services/
======
kevin_b_er
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
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.

------
mettamage
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
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
Wait, a 32-bit size_t?

~~~
ChrisSD
In a 32-bit processes, yes. You would expect differently?

~~~
trasz
Ah, right, thank you. I got it mixed up with off_t.

------
wyldfire
> 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
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.

~~~
pjmlp
As an additional note, SPARC supports a similar feature for pointer validation
and bounds checking in hardware.

Intel apparently is going in the opposite direction by removing MPX from their
future CUPs.

~~~
pcwalton
Because MPX is a terrible feature that no compiler vendor knows how to make
use of. By contrast, ARM PAC is relatively simple and obvious in operation.

Killing MPX is the right decision.

~~~
pjmlp
I trust your experience, having only read papers about it.

But then I would expect the feature to be replaced by something else instead
of being dropped as such.

Solaris with SPARC pointer validation turned on is a much secure platform in
spite of being written in C.

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

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

