Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

The previous blog post on the exploit chain got code execution with the mediacodec sandbox on Android. This is constrained by SELinux, where non-secure software is initialized. After reviewing the available attack surface, they found the driver /dev/bigwave was accessible from the sandbox. This is a Pixel SOC that accelerates AV1 decoding tasks, meaning it was intended to be accessible.

They had several issues pop out immediately in this driver. One was reported in February of 2024, but was still unfixed when the research was conducted a year later. Another bug was a double-free. They found one bug that was better than those, though: a UAF.

Whenever the device driver is opened, a new kernel struct labeled inst to store private data is created. Within this is a job that tracks register values and the job status. To submit work to the bigo hardware, a process called an ioctl is used to place the job in a queue and have it be used by a separate thread. In practice, this meant that an object whose lifetime was bound to a file descriptor was accessed by a kernel thread without any validity checks.

The actual UAF required a little trickery. The ioctl BIGO_IOCX_PROCESS submits a job to the bigo worker thread. In this, it enters wait_for_completion_timeout with a 16-second timeout. After this, the job is removed from the priority queue. If enough jobs are queued, the thread may exit early. If userland closes the file descriptor associated with BigWave, the job is destroyed while the worker thread still references it.

By spraying attacker-controlled kmalloc allocations, such as Unix Domain Socket messages, it's possible to control the job->regs. This allows for where and what is being written by the program. This creates a 2144 byte arbitrary write! From previous research, they found that 0xffffff8000010000 (.data) is static and contains many useful kernel globals. So, there's no need to defeat ASLR at all.

With some work with relability, it's possible to get a very reliable arbitrary read/write from the exploit. From there, they set SELinux permissions to permissive, fork a new process, and then set the new process's task creds to init_cred. They now have root credentials with SELinux disabled.