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!

This blog post is a bug in the Mesas llvmpipe Gallium3D graphics driver which was accessible via Chromium's WebGL. This driver is used to simulate GPU processing when the hardware is not available.

LLVMPipe is a software rasterizer that uses LLVM to compile the shader code to run on a CPU. The vulnerability is in the compilation process of shader code.

The vulnerability is in that the size of arrays is not validated within the shader code. When this is created, it is added to the stack as a variable length array (VLA).

Because there is no length check on the length of the array, the VLA can be mapped outside of the current stack mapping. This causes a crash because a guard page is hit within Chromium though. Can we do anything else with this?

Chromium has an additional exploit mitigation: all of the allocations are zeroed out before being used in order to prevent uninitialized memory leaks. Although, this causes issues because we don't want to write over the top of unmapped memory.

In order to prevent the initialization of zeros from happening, an always failing if statement can be used. In order to hop over the Guard Pages, we need to allocate a significant amount of memory in other locations.

By carefully fine-tuning the offsets for the VLAs, partial control over the RIP on the stack can be controlled. Eventually, with a few tricks for handling AVX instructions, the full RIP could be controlled!

To pop a full shell, this vulnerability would need to be chained with a memory leak. Additionally, the GPU runs in a sandbox which would require an additional vulnerability to break out.

This is an interesting vulnerability! This is the second VLA issue that I have seen in the last while; bounds checking on the high end needs to be taken seriously on stack memory in order to avoid these subtle issues.