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!

RenderDoc is a graphics debugger that allows for quick and easy introspection of graphics applications. It supports many different types such as Vulkan, D3D11, OpenGL and more. This is a write up on 3 vulnerabilities and the full exploits on them within RenderDoc.

librenderdoc.so is LD_PRELOADed into the application using a library load function. This works by creating a directory with /tmp/Renderdoc/ and calling open on a log file in this location with append mode. However, there is no validation on who owns the file, in the case that a malicious user wins this race.

The data is partially controllable by writing data to the TCP debugger server. Sadly, it has a major string header at the top that makes traditional configuration files not viable for escalation. How did they get around this? There's a call to fgets() within the systemd processing that only get 512 bytes at a time. By sending a very long string, we can use only our data on a given line.

An additional way to escalate privileges is to write to , using the truncation mentioned above they write to .config/user-dirs.defaults with SYSTEMD=.config/systemd to create a systemd directory in a user controlled location. By writing to a configuration file in this directory, code execution is trivial to achieve. To bypass the head issue again, the authors abuse a different in deliminators (\r) to add their own lines.

The second vulnerability is a heap based buffer overflow that occurs from unexpected sizes in processing the client name. This overflow does not seem very useful to start with but these people are wizards! When a thread of renderdoc starts up, glibc malloc allocates a new heap for the thread within an mmaped section of memory. This is always 64MB, aligned in 64MB groups and is mprotected for more security. This section is close to the libraries but there is a gap in memory.

The authors decided to use a technique that I've documented here. In glibc malloc, the mmap chunks have a special bit. By calling free() on an mmap chunk, the chunk isn't put into a free list; it's literally unmapped with munmap(). Arbitrarily mapping and unmapping memory is an incredibly powerful primitive. The munmap and mmap calls are the attack method but there is very crazy strategy to it.

They have a text picture explaining the setup. By using the vulnerability from before in the 64KB buffer, they are able to corrupt another mmap chunk directly ahead of it. Once the chunk ahead of it is updated to be extremely large. This is because we want the munmap() call to succeed. The goal is to punch a hole of exactly 8MB+4KB, which is the size of a threat stack and its guard page.

With the gap ready to go, we can allocate our data into that location that we want. This is done by simply connecting to the server, which creates a new thread in this gap, then disconnecting for this to be reused. After this, a large allocation of the client name (without triggering the vulnerability) will overlap with this section. I don't fully understand why this is the case but I'm assuming it's weirdness with munmapping memory.

With a long lived connection with our client name data being readable and overlapping with the stale client stack, we create a great primitive for reading and writing data. First, they force a new stack into this area. By doing this, a bunch of libc, stack addresses and much else can be leaked. After this, they use it to write to the RIP on the thread stack to hijack control flow with a large amount of ROP gadgets. It's weird that this works because of stack canaries though.

The final vulnerability is a fairly straight forward integer overflow that leads to a large amount of data being written to a small buffer. Overall, an amazing and innovative post. The shout out to me was appreciated and made my day!