COUNTERMEASURES - Hacking: The Art of Exploitation - page 352

sin_zero = "\000\000\000\000_
(gdb) x/s log_buffer
0xbffff1c0: "From 12.34.56.78:9090 \"GET / HTTP/1.1\"\t"
(gdb)

At the first breakpoint, client_addr_ptr is shown to be at 0xbffff7e4 and
pointing to 0xbffff810 . This is found in memory on the stack two dwords after
the return address. The second breakpoint is after the overwrite, so the
client_addr_ptr at 0xbffff7e4 is shown to be overwritten with the address
of the injected sockaddr_in structure at 0xbffff5cf . From here, we can peek
at the log_buffer before it's written out to the log to verify the address
injection worked.

0x662 Logless Exploitation

Ideally, we want to leave no trace at all. In the setup on the LiveCD, technically
you can just delete the log files after you get a root shell. However, let's assume
this program is part of a secure infrastructure where the log files are mirrored
to a secure logging server that has minimal access or maybe even a line
printer. In these cases, deleting the log files after the fact is not an option.
The timestamp() function in the tinyweb daemon tries to be secure by writing
directly to an open file descriptor. We can't stop this function from being
called, and we can't undo the write it does to the log file. This would be a
fairly effective countermeasure; however, it was implemented poorly. In fact,
in the previous exploit, we stumbled upon this problem.
Even though logfd is a global variable, it is also passed to handle_connection()
as a function argument. From the discussion of functional context, you should
remember that this creates another stack variable with the same name, logfd .
Since this argument is found right after the client_addr_ptr on the stack, it
gets partially overwritten by the null terminator and the extra 0x0a byte found
at the end of the exploit buffer.

(gdb) x/xw &client_addr_ptr
0xbffff7e4: 0xbffff5cf
(gdb) x/xw &logfd
0xbffff7e8: 0x00000a00
(gdb) x/4xb &logfd
0xbffff7e8: 0x00 0x0a 0x00 0x00
(gdb) x/8xb &client_addr_ptr
0xbffff7e4: 0xcf 0xf5 0xff 0xbf 0x00 0x0a 0x00 0x00
(gdb) p logfd
$6 = 2560
(gdb) quit
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: , process 27264
reader@hacking:~/booksrc $ sudo kill 27264
r eader@hacking:~/booksrc $

As long as the log file descriptor doesn't happen to be 2560 ( 0x0a00 in
hexadecimal), every time handle_connection() tries to write to the log it will
fail. This effect can be quickly explored using strace. In the output below,