COMPFEST 16 Finals
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.shlet'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 2we 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
days after, I realized that is it actually being printed and can be shown if I resize the terminal. it seems that the kernel prints without taking the terminal's dimension into account and not wrap it around as shown in the picture below

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