How to exploit binary with no syscall gadget or information leak in full ASLR and NX?

Question

So I have a Linux x86-64 binary linked with libc dynamically running on patched Ubuntu 16.04 remotely.

The executable makes one call to libc read and exits, allowing simple stack overflow into ROP. That's the only code compiled into the binary.

-----------------------
gdb-peda$ checksec
CANARY    : disabled
FORTIFY   : disabled
NX        : ENABLED
PIE       : disabled
RELRO     : Partial
-----------------------

Full ASLR is enabled.

I do not have access to a syscall gadget at any known address, and after hearing that vsyscall might work, I learned that vsyscall is now emulated in newer kernel versions and can't be used for a syscall gadget.

I've done manual searches for int 0x80, syscall, and sysenter hoping to find them in known executable section to no avail.

Does anyone know of any way to exploit this binary without any known address except for 'read'?

I suppose the only way that I can imagine is by somehow reading a libc address from the GOT and ROPing into dereferencing that address into a new function at a new offset... but I can't even find a gadget that will let me dereference.

I can't use partial address overwrite bruteforcing because x86-64 has too much entropy.

Is there some technique that I don't know of?

I'm banging my head against a wall on this one!

Answer 1

It ends up that the solution was using a partial address overwrite after all.

Using the address to read in the GOT, a two-byte partial address overwrite can be done to jump within a guarantee of 8192 bytes from read into libc, with a 1/16th brute-force chance to jump within 65535 bytes (due to 4 byte entropy of ASLR).

Within the two-byte overwrite, there is a magic gadget located 0x6109 bytes away from the address of read, which is within the two-byte distance.

From one_gadget, the magic gadget near read can be found:

0xf0567 execve("/bin/sh", rsp+0x70, environ)
constraints:
  [rsp+0x70] == NULL

Where in this version of libc (2.6.32), the call to read is found at:

0xF6670 read            proc near

Using a call to read, we can overwrite the GOT entry of read and ROP back to main to call our magic gadget.

Also, another solution was found by doing that same partial address overwrite to ROP into setting up a syscall then overwriting the last byte of read to jump 0x0E bytes forward and hit the natural syscall gadget found within read. This way you don't have to bruteforce ASLR and have a stable exploit!