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!

Everyone knows what a kindle is! Luckily for us, it has a wonderful attack vector: e-books. E-books are parsed in a multitude of file types with different parsers depending on the file type.

The architecture of the Kindle is tiered (wonderful diagram here). Of note, is the LIPC, which is an IPC library that links all of the Kindle components together. For instance, a HTML application (webkit) can use LIPC to interact with the native applications running.

The parsing starts with the Java functionality but gets passed on to native C libraries. As a result, the authors decided to focus on these libraries to hunt for memory corruption. How does Java interact with the library though?

The library functions have to be called somehow! By reversing the entry points in the Java file, they were apply to find the callable functions. In particular, openPDFDocumentFromLibrary, getCurrentPage and renderpageFromLibrary were used. These make excellent hooks for fuzzing!

The fuzzing setup for this did not pan out anything though. So, they decided to fuzz a specific object or stream filter or codecs from FoxIt technologies. They setup AFL in QEMU mode for the blackbox fuzzing the different stream types. Eventually, they found a bug.

The authors found an integer overflow on a oversized rectangle. When trying to expand the image to its new dimensions, there is no check that an overflow occurs. For example a result, an allocation of 0x100 is made when the actual size is 0x400000100.

The actual vulnerability occurs in the expand function, which is part of the refine functionality. By using the overflow to corrupt the refine data outside of our expected buffer for an arbitrary write primitive but only with XORed specific bits of memory.

The data and heap segments are RWX and ASLR is set to 1 on Linux; this means that the heap is not randomized! No further details are made on how a shell is popped within the process besides that it is trivial from here.

The next stage is to find a local privilege escalation bug to go from a user to root. After analyzing all of the permissions for this user, they found a flaw in the permissions. The database /var/local/appreg.db stores application registry information and it writable (without restrictions) to our user.

As a result, we can write an SQL query to change one of the command properties to a shell script that we own to become the root user. Game over :)

Defense in depth is important, even on modern day binaries. These protections need to be taken seriously in case of something like this. ASLR being set to 2 and PIE for the binary would have made this exploit much harder, if not impossible. Permissions are also important to check, even if they do not seem critical at the time.