COMPFEST 16 Finals

Team: seisyun complex

Rank: 3rd / 15

Challenge
Category

Camping

Binary Exploitation

Camping

Analysis

as per the usual kernel challenge, we're given the following files

└──╼ [β˜…]$ tree .
.
β”œβ”€β”€ bzImage
β”œβ”€β”€ camping.c
β”œβ”€β”€ initramfs.cpio.gz
└── launch.sh

let's examine at the environment by taking a look at launch.sh

#!/bin/bash

/usr/bin/qemu-system-x86_64 \
    -kernel $PWD/bzImage \
    -m 256M \
    -initrd $PWD/initramfs.cpio.gz \
    -nographic \
    -monitor none \
    -no-reboot \
    -cpu kvm64,+smep \
    -append "console=ttyS0 kaslr nosmap kpti=1 quiet panic=1 oops=panic" \
    -smp 2

we can see that KASLR, SMEP and KPTI is enabled but not SMAP.

now let's take a look at the challenge, thankfully the author has provided us with the kernel module source code. we can interact with the module through the IOCTL interface

  • KINTRO

this command assigns the global visitor fields.

  • KGREET

this one uses the plain printk() without any log level (i.e. KERN_INFO, KERN_DEBUG etc), which prints to the program's stdout that provoke it instead of kernel log through dmesg.

  • KVISIT

visit copies the decoration field to the address at location.

there are two function that I'm not familiar with here, first is access_ok()

access_ok -- Checks if a user space pointer is valid

which means the location field has to be an address within the user space.

second is isalnum() but I decided to take it for granted for its self explanatory name.

Exploitation

the first thing I take attention of is KASLR, one thing I took notice is printk(greeting); in KGREET which seems to be a format string vulnerability. so I took it to the test

However, even though I kinda already grasp the overall challenge and how to exploit it, this is ultimately where I got stuck because the address leak that we got from is somehow cropped

and so I thought I could use the f'%{offset}$p' format but as I test it, it doesnt seem to work. reading the printk's format documentation it does seems that the $ is not applicable

after the the competition had ended the challenge author told us that he uses newline (of course, why didn't I think of that) for the work around on this problem and it definitely worked

I took the address with the higher address i.e. ffffffff00000000 and try to find it's offset from the kernel base.

to make sure it's reliable and not affected by FG-KASLR, I tried running it multiple times and making sure the offset is not changed.

next, using stdin we'll take the address and calculate the kernel base

next to get the flag, we'll going to use modprobe technique, I won't explain it in depth since there are other people who had done the job better than I could've had linked below:

first let's get the modprobe_path address and its offset (also as previously, double check to make sure its not affected by FG-KASLR)

to exploit it, we would need to have arbitrary write primitive, we could've easily had this through KVISIT:

however access_ok() will be denying our request since the address would be one in the kernel space instead of user space.

this could be bypassed through the vulnerability called double fetch explained here:

this is also similar to a challenge I have previously solved which is HTB's Kernel Adventures: Part 1

to do this, we'll need two asynchronous execution, one thread will continuously request for KVISIT, trying to trigger the memcpy :

while the other thread will continuously swap the values of location to satisfy access_ok() and decoration to satisfy isalnum() in the hopes that the race will satisfy both of the checks while contains our payload to overwrite modprobe by the time memcpy is called.

before all this, we might want to set up the modprobe files to make it more efficient

while the exec_modprobe() will just try to execute modprobe and check if the is now exists

lastly, fired up the threads and hope you'll win the race

below is the full exploit:

Last updated