Re: ufsrestore sparc exploit

[jmcdonal () UNF EDU (John McDonald)]

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