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!

While playing around with the GreatFET One, the author found that Xorg would crash with format string payloads. After an advisory from Xorg that related to "input devices" the author decided to investigate to see if these bugs were the same thing.

A format string is commonly used in many programming languages. In C, it has the potential for horrible memory corruption bugs though. When a printf family function is called, it takes in a string with format specifiers (%x, for instance) and a variable amount of arguments depending on the format specifier. If an attacker can control the string, then they can trigger the format specifier functionality on unintended data.

In the case of Xorg, libinput is performing logging. While doing this logging, it is creating a format string dynamically by prepending a string with sprintf to be used later in another printf-like call. Because of this string concatenation for a format string with user controllable values, this created a fairly bad format string bug. This bug is explained at here.

Since the root causing had already been done, the author decided to write up a proof of concept for it; the goal was to leak the stack canary. Immediately, the author ran into two problems. First, there is a length limit of an individual field is 126 characters. Secondly, because the data was being prepended and there was a %s in the end of the string, almost everything caused a crash. Finally, FORTIFY_SOURCE=2 was set on the binary, disallowing the usage of the %N for writes.

To solve the %s crash problem, direct parameter access in the format string could be used. Since this doesn't increase the pointer being used for the stack, this was a good solution to the problem. Additionally, direct parameter access cannot skip any values because of FORTIFY_SOURCE=2 being set. Because of this and the length constraint, the furthest byte that can be accessed is 27.

Now, the format string is not too bad looking It ends up being %1$p%2$p...%27$p, which is parameterized access for all 27 bytes. Depending on the location of the field in the payload, this would leak the stack canary in the last few bytes. Damn, that's super awesome!

The author got this to work on Xubuntu 20.04.4. They tried this on Deban 11 systems but couldn't get it to work. Most distros have all binary protections, such as canaries, RELRO and things in place. They tried get code execution using this but the FORTIFY checks were just too much to overcome this.

Overall, I love the post from a practical side. First, this bug should have been caught by the compiler but wasn't because some flags were turned off. Second, the exploit is practical and shows the complexity with real world exploits and exploit mitigations. Great job!