Google Android – Inter-Process munmap with User-Controlled Size in android.graphics.Bitmap
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=928 Bitmap objects can be passed between processes by flattening them to a Parcel in one process and un-flattening them in another. In order to conserve memory, there exists a code path which allows Bitmaps to be shared between processes by providing an ashmem-mapped file descriptor containing the Bitmap's raw pixel data. The android.graphics.Bitmap class illegally assumes that the size of the ashmem region provided by the user matches the actual underlying size of the Bitmap. When un-flattening a Bitmap from a Parcel, the class first calculates the assumed size of the Bitmap from the user-provided dimensions. Then, it calls Parcel::readBlob in order to map the given ashmem file descriptor to the process's VAS. This mapping is done using the size calculated from the Bitmap's dimensions (and not the size of the underlying ashmem descriptor). Later, the Bitmap constructor internally stores the ashmem file descriptor and mapped memory address, along with the size of the mapping. However, instead of using the same calculated size which was used when mapping the shared memory region, it accidentally queries the ashmem region for its real size, like so: mPixelStorage.ashmem.size = ashmem_get_size_region(fd); This size can be completely controlled by an attacker (simply by calling ASHMEM_SET_SIZE), and may be arbitrary large. Later, when the Bitmap is GC-ed, the destructor triggers a call to Bitmap::doFreePixels which unmaps the Bitmap's data, by calling: munmap(mPixelStorage.ashmem.address, mPixelStorage.ashmem.size); This means that an attacker can cause the size of the unmapped region to be arbitrarily large, thus unmapping crucial regions in the remote process's VAS. One example of how this can be exploited is by unmapping the remote process's heap (which is directly after the mmap-ed ranges on the device I was working on). Then, the attacker can resend a large Bitmap which will be mapped over the (previously unmapped) heap, thus allowing the attacker to effectively replace the remote process's heap with controlled data. I've attached a short PoC which crashes system_server by repeatedly unmaps large memory regions. Suggested Fix: Store the calculated size in mPixelStorage.ashmem.size instead of calling ashmem_get_size_region. Here's a brief run-down of the exploit: 1. The exploit begins by calling AudioService.unloadSoundEffects in order to close the SoundPool instance in system_server. This also closes any auxiliary threads (SoundPool, SoundPoolThread, etc.) that are associated with this pool. 2. Now, we start "massaging" system_server's VAS. This is done by creating multiple "Notification" objects which contain Bitmaps that are of exactly the same size at a thread's stack, when created by the ART runtime. As the bitmaps are allocated by using "mmap", they will simply inhabit the highest memory address between mm->mmap_base and TASK_SIZE which contains a sufficiently large contiguous hole. Causing many allocations of the aforementioned size will ensure that any "holes" of this size in higher addresses are filled, and the remaining "mmap"-s of this size will be contiguous. 3. Now that we are certain allocations of size THREAD_SIZE are contiguous, we replace one of notifications created in the previous stage with a notification containing a small (or empty) bitmap, and immediately send multiple dummy transactions to system_server in order to force garbage collection of the freed bitmap object. This will enable us to open up a "hole" in the contiguous allocations, like so: <--low high--> ---------------------------------------------------------------- | Bitmap | Bitmap | Bitmap | Bitmap | Bitmap | Bitmap | Bitmap | ---------------------------------------------------------------- || \/ <--low high--> ---------------------------------------------------------------- | Bitmap | Bitmap ||||hole|||| Bitmap | Bitmap | Bitmap | Bitmap | ---------------------------------------------------------------- 4. Now that there's a THREAD_SIZE-sized hole opened up, we can call AudioSystem.loadSoundEffects() in order to re-create the SoundPool object within system_server. This will allocate a new "SoundPoolThread" thread in system_server, which (after brief initialization) enters a polling loop on a condition variable (or rather, a futex), waiting for messages to be enqueued. However, this thread's stack will be directly mmap-ed in our previously created hole, like so: <--low high--> --------------------------------------------------------------------------- | Bitmap | Bitmap |SoundPoolThread stack| Bitmap | Bitmap | Bitmap | Bitmap | --------------------------------------------------------------------------- 6. Now, similarly to step 3., we can free the chunk directly before the previously unmapped chunk, creating the following state: <--low high--> ----------------------------------------------------------------------------- | Bitmap ||||hole||||SoundPoolThread stack| Bitmap | Bitmap | Bitmap | Bitmap | ----------------------------------------------------------------------------- 6. Finally, we send our "poisoned" bitmap object, which should get allocated directly in front of the SoundPoolThread's stack. Then, we force garbage collection once more, resulting in both the bitmap and the SoundPoolThread's stack being unmapped. However, since the SoundPoolThread is still waiting on a futex, this is fine. Here's what this stage looks like: <--low high--> -------------------------------------------------------------------------------- | Bitmap |Poison Bitmap|SoundPoolThread stack| Bitmap | Bitmap | Bitmap | Bitmap | -------------------------------------------------------------------------------- || \/ <--low high--> -------------------------------------------------------------------------------- | Bitmap ||||||||||||||||hole||||||||||||||||| Bitmap | Bitmap | Bitmap | Bitmap | -------------------------------------------------------------------------------- 7. At this point we can enqueue another notification, this time backed by a specially crafted ashmem file, containing two separate pieces of information: a. A chunk of position independent ARM/ARM64 code, followed by b. A ROP stack This notification will be of size THREAD_SIZE*2, and will therefore fill up the hole we just set up, resulting in the following state: <--low high--> ------------------------------------------------------------------- | Bitmap | PIC code | ROP Stack | Bitmap | Bitmap | Bitmap | Bitmap | ------------------------------------------------------------------- 8. Now, we can safely call AudioService.unloadSoundEffects() once more. This will signal the condition variable that SoundPoolThread was waiting on, but now when it returns it will be executing our own ROP stack. The ROP stack simply mmap-s the ashmem file descriptor with PROT_EXEC and jumps into it (essentially executing the PIC code we supplied). Proofs of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40874.zip |