On Wed, 24 Jun 1998, Aggelos P. Varvitsiotis wrote: > Whatever the "fix" was, it has not prevented the long argument from > smashing ufsrestore's stack, but has simply moved the code location > something more than 100 bytes higher on the stack. The original > code even takes an optional argument for this, so no recompilation > is needed; the exploit works like a charm: I probably should have explained the exploit a little when I posted it. I started messing around with ufsrestore when the Sun advisory came out and couldn't get anywhere with the overflow on the command line. So, I thought that maybe that wasn't the hole that the Sun advisory was addressing. Eventually, I found that I could crash it another way: by making argv[0] rather large via an exec and hitting ctrl-c before ufsrestore errored out. Apparantly, a signal handler probably strcpys or sprintfs argv[0] into a buffer it allocates off of the stack. From what I understand, the kernel will set up an activation record for a signal handler on the top of the user's stack, so thus, it is exploitable. I'm not sure about the ramifications of the register windows in the Sparc architecture in this situation because it is such a wierd case, but what I think what is happening is that the program returns from the signal handler, and then hits another return in the code, which gets our instruction pointer popped. It could also be possible that the signal handler returns into some sort of signal cleanup code to restore the signal mask (like linux does I think), and then that returns, which will pop our instruction pointer off of the stack (because it would have had to have been saved). Perhaps someone with more knowledge or source could explain what actually happens in this situation. To clarify, I believe that this is a different problem in ufsrestore than the Sun released advisory deals with, due to the fact that people have told me the patch is ineffective. I haven't personally tested it on a patched machine. I've had a lot of people contact me and tell me that the exploit either works on all of their machines, or doesn't work at all. The way I originally wrote it, it jumps into where argv[0] sits above the stack. Assuming that solaris works the same way as bsd in this respect (please correct me here), the memory looks like this: env strings argv strings env pointers argv pointers stack So, the exploit's fake return address was based upon the offset between a place in the stack, and the first argv[] string. The problem with this is that if someone has a different number of env variables defined, the number of env pointers will be higher, and the accuracy of the guess will be shot. So, you can either mess with the offset by passing an argument that is a multiple of 8, or you can rewrite it to jump into the stack. (just gdb a core dump and do x/42 0xefffd000 or somewhere near that (sometimes its at 0xdfffxxxx on some 2.4 boxes i think) and hit enter until you find the shellcode). humble
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:59:26 PDT