Re: Vulnerability in the Xt library

[casper () holland Sun COM (Casper Dik)]

>  Both Sun's compiler and gcc allocate the stack as follows:
>
>  %fp - 2008  == message
>  %fp - 1008  == buffer
>
>  At the call to sprintf(), 'buffer' contains something like
> "Invalid color: %s\0", and 'message' is the thing we're going to overflow.
>
>  If we overflow 'message' to overwrite the return addr, we *ALSO* overwrite
> 'buffer'. As a result, the formatting string for sprintf is completely
> obliterated, which forces _doprnt() to segfault (as there's no termination
> for its formatting string).


This pretty much depends on how doprnt works (also, the vs 3 compiler from
Sun has different stack allocations, depending on the optimization).


After processing the %s format, sprintf will suddenly find much more
format.  However, if there's no % in the format, there's still a way to prevent
sprintf looping for ever, it all depends on how the format is processed.


If your sprintf processes it character by character and copies each character
then the format will never end.  However, if the format is copied chunk
by chunk between each % or the terminating \0, then doprnt will finish.

This is the way doprnt() works in Solaris.

My "point & shoot" stack overflow exploiter works on Solaris xterm
[which isnt' set-uid] with the "sub optimal" stack layout as above:

% bufoverflow /usr/openwin/bin/xterm -fg %s
Warning: Color name "<lotsajunk>"  [with a part of the buffer repeated!!]
Warning: some arguments in previous message were lost
$

The $ is the shell started by the buffer spam.

It's definitely possible, even with the stack layout as described by you.
(Which, incidently, is the stack layout used in Solaris as shipped)

Casper