Exploits / Vulnerability Discovered : 2019-03-06 |
Type : dos |
Platform : android
This exploit / vulnerability Android getpidcon() usage in hardware binder servicemanager permits acl bypass is for educational purposes only and if it is used you will do on your own risk!
[+] Code ...
We already reported four bugs in Android that are caused by the use of
getpidcon(), which is fundamentally unsafe:
https://bugs.chromium.org/p/project-zero/issues/detail?id=727 (AndroidID-27111481; unexploitable)
https://bugs.chromium.org/p/project-zero/issues/detail?id=851 (AndroidID-29431260; getpidcon() used in the servicemanager)
https://bugs.chromium.org/p/project-zero/issues/detail?id=1404 (AndroidID-68217907; getpidcon() used in the hardware service manager)
https://bugs.chromium.org/p/project-zero/issues/detail?id=1406 (AndroidID-68217699; getpidcon() used in the keystore)
The bulletin entry for bug 1404 (in
https://source.android.com/security/bulletin/2018-01-01#system) points to the
following three commits:
https://android.googlesource.com/platform/system/libhidl/+/a4d0252ab5b6f6cc52a221538e1536c5b55c1fa7
"canCastInterface: always return true for IBase"
I'm not sure how this relates to the bug.
https://android.googlesource.com/platform/system/tools/hidl/+/8539fc8ac94d5c92ef9df33675844ab294f68d61
"Explicitly check processes are oneway"
Ensures that the caller PID isn't passed as zero. This addresses a second issue
that was mentioned in the bug report, but doesn't address the core issue.
https://android.googlesource.com/platform/system/hwservicemanager/+/e1b4a889e8b84f5c13b76333d4de90dbe102a0de
"get selinux context on add call arrival."
"interfaceChain may take too long and allow for the PID to become invalidated."
This seems to be the patch that is intended to fix the core bug - but all it
does is to reduce the size of the race window, it does not address the actual
issue.
Overall, it looks like this vulnerability was not actually fixed.
A patch that merely reduces the size of a race window without eliminating it is,
in my opinion, not a valid fix for security issues that impact confidentiality
or integrity.
(The situation in the classic servicemanager seems to be similar, except that it
has additional checks that very coarsely mitigate this class of issues based on
caller UIDs.)
In my opinion, a proper fix should include tracking of caller SELinux contexts,
perhaps with context information pulled from the kernel on demand when needed.
I think you could e.g. implement this by stashing a refcounted pointer to the
caller's credentials in the struct binder_buffer in binder_transaction(), like
this:
t->buffer->caller_cred = get_current_cred();
And then add a new ioctl to the binder device for looking up the SELinux context
associated with a transaction, somewhat similar to SO_PEERSEC: Take the alloc
mutex, look up the allocation for the provided userspace pointer, ensure that it
is user-freeable, take a reference to its creds, and drop the mutex.
If for some reason, this still has too much overhead, you could also gate it on
opt-in by the receiving binder, similar to FLAT_BINDER_FLAG_ACCEPTS_FDS.
To demonstrate that this issue can indeed still be triggered, I have written a
PoC for the Pixel 2 (walleye), running build
"google/walleye/walleye:9/PQ1A.181205.002/5086253:user/release-keys"
(patch level "2018-12-05") that can register a second instance of
"android.hidl.manager@1.0::IServiceManager" with instance name
"bogusbogusbogus".
Note: It will probably take a few minutes when you run it the first time because
it has to create a 16GB file on disk.
Once the PoC has printed "REGISTRATION OVER", the bogus hardware service should
have been registered. The PoC will keep running to keep the bogus service alive.
master.c coordinates execution.
register.c takes care of setting up two processes that share memory mappings,
wrapping the PID counter, registering a service and relinquishing the PID at the
right time.
thread_spawner.c uses the unloadSoundEffects() and loadSoundEffects() RPC calls
on android.media.IAudioService to create a thread in system_server, reusing the
PID relinquished by register.c.
reload_timer.c stalls slowpath lookups of entries in /proc for ~15 seconds by
abusing that Linux 4.4's sys_getdents64() exclusively locks the inode across the
entire readdir operation, including all usercopy accesses, combined with a
series of uncached 4k file mappings and a lack of priority inheritance in kernel
mutexes. Stalling slowpath lookups of /proc entries causes getpidcon() to block
on opening /proc/$pid/attr/current.
See also the attached timing diagram.
Oh, by the way, something else that I'm not actually using here, and that
doesn't really have any direct security impact, but that looks unintended:
/dev/binder sets the VM_DONTCOPY flag on the VMA, but because it doesn't also
set VM_IO, it is possible to use madvise(..., MADV_DOFORK) to clear that flag:
case MADV_DOFORK:
if (vma->vm_flags & VM_IO) {
error = -EINVAL;
goto out;
}
new_flags &= ~VM_DONTCOPY;
break;
Proof of Concept:
https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/46504.zip
Android getpidcon() usage in hardware binder servicemanager permits acl bypass