After working a bit on this and discussing it off-list, we found the
problem. Recall the portion of of server code:
void backup(char* bkFromName, int nmlen)
{
inbackup(bkFromName, nmlen);
}
void inbackup(char *bkFromName, int nmlen)
{
char tempDir[12];
memcpy(tempDir,bkFromName, nmlen);
}
The problem is that between where makemsg_1 calls backup and the memcpy in
inbackup, the register windows aren't being flushed to the stack and the
overflow isn't overwriting any saved registers (as Dave Aitel suggested
and I doubted, my apologies).
Several things would cause the register windows to be written out: a
window overflow trap, a process context switch, or a mode switch. If
the function call graph from inbackup goes deeper than the number of
windows (from 3 to 32, but usually around 10), then inbackup's register
window will be written to the stack. A process context switch will also
do this, but as there is very little work done before the memcpy, the
chance of a context switch happening is very slim. Also, any system call
(or a library function that uses one) would cause a mode switch to the
kernel and all the processes' windows will be written out. Putting a
printf() or getuid() before the memcpy is enough to make the overflow
work.
Most of the techniques described previously (loading a machine down and
writing a ton of return addresses) are meant to overcome situations where
a context switch or mode switch isn't happening. Loading the machine down
increases the probability of a context switch in the critical section
before the overflow. Writing a ton of return addresses attempts to
overwrite the saved program counter of any saved register window up the
stack (anywhere 3-32 frames spaces up). In this case, however, the best
solution was making the vulnerable server actually do some work before the
memcpy (this would most likely be the case in a real vulnerable server
anyway).
--
ghandi / ghandiat_private / www.dopesquad.net
"Bein' Crazy is the least of my worries." - Jack Kerouac
C439 2B06 D8D2 A2D8 1ABB 0A55 A61D 9057 63F5 9B1F
This archive was generated by hypermail 2b30 : Thu Nov 08 2001 - 14:11:37 PST