Android ashmem readonly bypasses via remap_file_pages() and ashmem_unpin Vulnerability / Exploit
/
/
/
Exploits / Vulnerability Discovered : 2020-01-14 |
Type : dos |
Platform : android
This exploit / vulnerability Android ashmem readonly bypasses via remap_file_pages() and ashmem_unpin is for educational purposes only and if it is used you will do on your own risk!
[+] Code ...
This bug report describes two ways in which an attacker can modify the contents
of a read-only ashmem fd. I'm not sure at this point what the most interesting
user of ashmem is in the current Android release, but there are various users,
including Chrome and a bunch of utility classes.
In AOSP master, there is even code in
<https://android.googlesource.com/platform/art/+/master/runtime/jit/jit_memory_region.cc>
that uses ashmem for some JIT zygote mapping, which sounds extremely
interesting.
Android's ashmem kernel driver has an ->mmap() handler that attempts to lock
down created VMAs based on a configured protection mask such that in particular
write access to the underlying shmem file can never be gained. It tries to do
this as follows (code taken from upstream Linux
drivers/staging/android/ashmem.c):
This ensures that the protection flags specified by the caller don't conflict
with the ->prot_mask, and it also clears the VM_MAY* flags as needed to prevent
the user from afterwards adding new protection flags via mprotect().
However, it improperly stores the backing shmem file, whose ->mmap() handler
does not enforce the same restrictions, in ->vm_file. An attacker can abuse this
through the remap_file_pages() syscall, which grabs the file pointer of an
existing VMA and calls its ->mmap() handler to create a new VMA. In effect,
calling remap_file_pages(addr, size, 0, 0, 0) on an ashmem mapping allows an
attacker to raise the VM_MAYWRITE bit, allowing the attacker to gain write
access to the ashmem allocation's backing file via mprotect().
Reproducer (works both on Linux from upstream master in an X86 VM and on a
Pixel 2 at security patch level 2019-09-05 via adb):
Interestingly, the (very much deprecated) syscall remap_file_pages() isn't even
listed in bionic's SYSCALLS.txt, which would normally cause it to be blocked by
Android's seccomp policy; however, SECCOMP_WHITELIST_APP.txt explicitly permits
it for 32-bit ARM applications:
# b/36435222
int remap_file_pages(void *addr, size_t size, int prot, size_t pgoff, int flags) arm,x86,mips
ashmem supports purgable memory via ASHMEM_UNPIN/ASHMEM_PIN. Unfortunately,
there is no access control for these - even if you only have read-only access to
an ashmem file, you can still mark pages in it as purgable, causing them to
effectively be zeroed out when the system is under memory pressure. Here's a
simple test for that (to be run in an X86 Linux VM):