Kernel heap corruption (SLUB) - CSAW17 Finals

TL;DR CSAW17 finals - kws2 write-up is here.

During the last three years of CTF games I did nothing but reverse engineering challenges. Started as a solo-player with pure reversing competitions, I ended up playing in a cool team with great guys. The NOPS team from the S3 group.
The rev category is still my first pick in every CTF even if I'm slowly integrating with pwning, exploitation challenges.

Last year me and some NOPS mates played CSAW17. After the qualification round we got to the finals (hurray:D), where we ranked 2nd in Europe and 8th worldwide. We didn't flag only few challenges including the second part of kws2, a buggy kernel module.
kws2 was about a key-value store for Python objects running in kernel-land. However, the code was lacking an important boundary check. A properly crafted input was enough to overflow the store on the kernel heap memory and - after some months - get a privileged shell on the machine.

You read after some months, yes. Maybe a little bit too late for the CTF but still in time to understand how to do it the right way. After some months because we were missing the details of how the kernel controls its heap. After some months because: how does the SLUB allocator work? Perfect moment to deep into the internals of the kernel SLUB allocator and have a look at how it's implemented.

This quick post is just to tell you that we finally have a (long-)write-up and a working exploit I wrote for kws2!
You can find both HERE.

Lesson learned:

• there is no magic - understand the low-level details and you will get through it;
• touch with hands - a CTF challenge may be sufficient to materialize theoretical knowledge;
• it's never too late - you miss a flag but you know how to start the next time.