Towards Automating Code-Reuse Attacks Using Synthesized Gadget Chains

Abstract

In the arms race between binary exploitation techniques and mitigation schemes, code-reuse attacks have been proven indispensable. Typically, one of the initial hurdles is that an attacker cannot execute their own code due to countermeasures such as data execution prevention (DEP, ). While this technique is powerful, the task of finding and correctly chaining gadgets remains cumbersome. Although various methods automating this task have been proposed, they either rely on hard-coded heuristics or make specific assumptions about the gadgets’ semantics. This not only drastically limits the search space but also sacrifices their capability to find valid chains unless specific gadgets can be located. As a result, they often produce no chain or an incorrect chain that crashes the program. In this paper, we present SGC, the first generic approach to identify gadget chains in an automated manner without imposing restrictions on the gadgets or limiting its applicability to specific exploitation scenarios. Instead of using heuristics to find a gadget chain, we offload this task to an SMT solver. More specifically, we build a logical formula that encodes the CPU and memory state at the time when the attacker can divert execution flow to the gadget chain, as well as the attacker’s desired program state that the gadget chain should construct. In combination with a logical encoding of the data flow between gadgets, we query an SMT solver whether a valid gadget chain exists. If successful, the solver provides a proof of existence in the form of a synthesized gadget chain. This way, we remain fully flexible w.r.t. to the gadgets. In empirical tests, we find that the solver often uses all types of control-flow transfer instructions and even gadgets with side effects. Our evaluation shows that SGC successfully finds working gadget chains for real-world exploitation scenarios within minutes, even when all state-of-the-art approaches fail.

Appendices

A Modeling

Byte-wise memory reads and writes are modeled using single select and store operators, respectively. Larger reads are modeled by concatenating multiple select expressions, which we define recursively in terms of smaller read operations. Reads smaller than 64-bit into a 64-bit register are zero-extended by using concat with the zero bit vector $bv_0$. Larger writes are similarly modeled using the composition of multiple store expressions. Table 6 shows memory accesses of various sizes. Given an array m, address k and value v and bit size $n \in (8, 16, 32, 64)$, we use the names $mem\_read_n(m, k)$ and $mem\_write_n(m, k, v)$ to substitute the longer SMT expressions from these tables.

Table 6. Encoding of memory reads and writes (m: memory, k: address, v: value).

B dnsmasq CVE-2017-14493

In the following, we analyze the dnsmasq bug in more detail. The stack-based buffer overflow in dnsmasq is caused by the absence of a length check of the data copied to a static buffer on the stack. Figure 2 shows the vulnerable call to memcpy in function dhcp6_maybe_relay. Sending a malicious DHCPv6 packet allows to gain control over the instruction pointer by overflowing the mac buffer of static size DHCP_CHADDR_MAX (16) in the state structure present on the stack.

Fig. 2.

Vulnerable memcpy in file rfc3315.c, which overflows the mac buffer in state.

The proof-of-concept (PoC) provided alongside the bug report [25] builds up such a DHCPv6 packet containing an OPTION6_CLIENT_MAC option holding data of excessive length. While the PoC overwrites the instruction pointer with a dummy value, injecting an arbitrary amount of bytes is possible. As long as the stack is not exhausted, the packet’s content is copied and remains untouched until the instruction pointer is overwritten.

In order to synthesize a gadget chain, the information needed to specify preconditions and postconditions is gathered by extracting the program state before hijacking the control flow through GDB. Table 7a shows the preconditions set for dnsmasq. The initial ret instruction, which redirects the control flow to the chain’s first gadget (gadget_0), is specified by preconditioning rip. The stack pointer rsp points to the part of the controlled buffer, where the gadget chain will be copied. In the logical formula, this stack area is a free variable.

Table 7. Preconditions and postconditions used for dnsmasq. Registers not mentioned in the preconditions are free variables, i. e., registers an attacker controls and can set to an arbitrary value.

Since we want to execute a system call to execve to spawn a shell, the final register values which the gadget chain needs to reach are specified accordingly. Table 7b shows the postconditions in preparation for calling execve(&"/bin/sh", 0, 0). Here, rip holds the address of a syscall instruction available in the program. Using the default configuration described in Sect. 5.1, SGC finds a gadget chain consisting of four gadgets within approximately 8m. While most gadgets are straightforward, gadget_3 (shown in Fig. 3) writes a value to the stack outside the attacker-controlled buffer, a side effect that does not harm the chain. The arithmetic operations of the first four instructions do not change register rax’ value of 0. In line 6, the lea instruction is used to add 0x5 to the value present in $\texttt {rbp} = \texttt {0x55555559a1cb}$. The resulting address, 0x55555559a1d0, is a syscall instruction; the address is placed on the stack at address 0x7fffffffe240 present in register rbx. As this address is writable memory, no harm results from this side effect.

Fig. 3.

gadget_3 of the gadget chain used to spawn a shell in dnsmasq.

As mentioned earlier, the PoC crafts a rogue DHCPv6 packet. In order to construct the payload with our synthesized gadget chain, the length parameter is adjusted and the dummy value is replaced with the data of the gadget chain. Sending this packet to the dnsmasq DHCP server successfully spawns the shell.