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 SFQ Qdisc system in Linux distributes fair packet throughput between different network data flows. If the packet amount exceeds the limit, it's dropped. Eventually, a type confusion occurs through a complex interaction of 3 packets. This type-confusion leads to an integer underflow on an index, leading to an out-of-bounds write with the value 0x0000. In practice, it writes 262636 bytes (4 * 0xFFFF) after the vulnerable Qdisc object.

The initial vulnerability was patched by not allowing a limit of 1 on the QDisc limit. However, it can get SET to 1 because of a min operation performed later. This was discovered through Google Syzkaller fuzzer. Is a two-byte uncontrolled location and uncontrolled set of bytes even useful for a primitive? Memory corruption is a powerful beast! The focus of the article is on the exploitation of this issue.

The first goal was to reduce the number of crashes. Right after the OOB write occurs, two invalid pointer accesses occur. One of them can be conquered by spraying valid objects with pointers in the proper malloc slab. The other case was a little more tricky - they solved it using application-level setups to ensure that the path that led to a crash never happened. Now, the OOB is stable!

The offsets where this exploit could take place were very limited. They had previously made a tool that converts the Linux structures to a Python-queryable interface and searched for all fields within these ranges that could be useful. After a lot of review, they came across the pip_inode_info.files field in the kmalloc-192 slab. From reading this code, they could set a counter to 0 to trigger a page-level use after free!

With a page-level write, the author figured out how to overwrite the process credentials with zeros to get root privileges. This exploit worked about 35% of the time. To make this more reliable, there are likely side channels to work around one of the main crashes. On the mitigation instance, they found guard pages reduced the exploitation substantially.

Overall, a super technical and excellent blog post on exploiting the vulnerability. At first glance, this seems unexploitable but this just proves how powerful memory corruption can be. I found the section on making the aftermath not crash to be super interesting as well.