Muli Ben-Yehuda's journal

Shachar Shemesh has a few comments on the hacking contest. He thinks that “the kernel challenge was not planned properly… what Muli did to the kernel pales in comparison to things you see in the real world”. I guess what Shachar doesn’t understand is that it was supposed to be hard, not impossible. We could’ve been a lot more evil, and made their lives much harder, but what would’ve been the point in that? it was supposed to be fun, and solvable within an hour.

We intended for the teams to understand that the kernel has been tampered with, find in what way it was tampered with, find the backdoor in the tampering, and finish this stage. This is exactly what the winning team did. We anticipated the teams trying to boot with a clean kernel (this is exactly what we would’ve done in their stead) and took steps to prevent that from working (only our kernel would agree to mount the minix file system that the file resided on – a one bit change in the magic field in the superblock is all it took).

Shachar’s team “solved” this stage in two ways – the first, by removing the loopback mount and creating a different file at /usr/local/august/stage3.tmp. This is something we considered a low-quality solution, since it did not solve the original problem, only worked around it. Their second solution was “we did something and the file changed, and we don’t know what it was”. We accepted it, since the file did appear to be changed, but it would’ve been nice if they would’ve known how they did it. It’s possible that they exploited a bug in my patch, or tricked us somehow, but since the winning team rm -rf’d their machine at the end, we will never know.

It was fun and we certainly learned a few things for the next time. And Shachar, I could’ve written a complete root kit, but considering how long it took you guys to handle this relatively simple challenge – what would’ve been the point?

Aviram Jenik, overlord of BeyondSecurity has an excellent technical writeup of the hacking contest. Sorry, it’s in Hebrew.

August Penguin 2004 happened on Friday morning, and was a blast. My
august-2.6.8-rc2bk8-E1
patch which was used in the hacking competition is available on the kernel page.

This is august-2.6.8-rc2bk8-F1,
a small patch I wrote for the August Penguing 2004
Linux convention hacking
contest. The contest had several stages. In each stage,
the contestants needed to perform a task. For stage 3, the
task was to change a file named ‘stage3.tmp’. The obstacle in
their way was this patch.

The patch has two parts: the first is a Linux Security
Module named “august.c”, which protects this file from
unwanted access via the LSM hooks. It also has a small
backdoor – it only works if the date is after the beginning
of August 2004. Contestans were expected to find the patch
(we left the sources on the machines), discern the backdoor,
change the date, and win. Version -E1, which was used in the
competition, also had some interesting “side effects” like
zeroing the file whenever it was accessed.

In order to prevent the contestants from booting with a
non-modifed kernel and changing the file there, we put the
file on a loopback mounted minix file system. This minix
file system had a non standard magic number in its
superblock, which means that only a kernel that had a patch
to its minix fs code to recognize our minix magic number
would agree to mount it. This is the second part of the
patch.

(prev: -A1,
-B1,
-C1,
-D1,
-E1)