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!

Pwn2Own is a contest where contestants compete for the master of pwn. The author decided to tackle the very hardened target VirtualBox.

While searching through the code, looking for interesting attack vectors, they noticed a memcpy on Generic Segmentation Offload (GSO) used in NAT emulation. After analyzes various code paths and using a SMT solvers, they discovered that they could control a fair amount of information from this memcpy. Good attack surface to start!

The specific code path, with a lot of control, was via paravirtualized networking. Paravirtualization has the guest install drivers that aware they are running in a virtual machine in order to work with the host to transfer data. One of these drivers is the virtio-net driver, which comes with the Linux sourc as a network adapter.

Generic Segmentation Offload (GSO) is for putting the heavily lifting of checksums for network traffic or segmentation of Ethernet packets. GSO is implemented via VirtIO to speed up the process of generating this information.

When the NAT code receives the GSO frame, it gets the full Ethernet packet to pass to a library for TCP/IP emultation called Slirp. There is a buffer allocated for this packet, along with a size for the allocation. There is an Assertion if the size is too big. However, the assets are NOT compiled into release builds. Since the default size is the smallest bucket of sizes, this leads to problems.

An additional vulnerability occurs in the validation of the guest GSO parameters. Even though this validation exists, the same assertion bug as above exists. As a result, a heap overflow can occur.

In the CheckSum offload ecosystem a size parameter is blindly trusted without any validation. This bug leads to an integer underflow or an out of bounds read access. Checksumming too much data does not seem interesting at first glace; however, by doing this multiple times, this turns into a weirdly complicated out of bounds read vulnerability.

Sadly, no exploitation details were given. However, it is assumed that the vulnerabilities can be used to escape the virtual machine. To me, the most interseting part is that there are multiple types of asserts in the library. One of them is compiled into the system while the other is only in some builds, but NOT the production builds. This seems to be a common problem and is worth checking out in other places.