[7572] in bugtraq
Re: resend
daemon@ATHENA.MIT.EDU (Casper Dik)
Fri Aug 7 18:46:31 1998
Date: Fri, 7 Aug 1998 21:37:21 +0200
Reply-To: Casper Dik <casper@HOLLAND.SUN.COM>
From: Casper Dik <casper@HOLLAND.SUN.COM>
X-To: Steve Bellovin <smb@RESEARCH.ATT.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: Your message of "Thu, 06 Aug 1998 13:53:40 EDT."
<199808061753.NAA14285@postal.research.att.com>
>No one worried much about stack-smashing in those days. It would have
>been a difficult attack, though, since the stack grew up, and local
>variables would have been allocated after the save area. (While the
>current routine's save area didn't have the actual return address, by
>convention it had a back-pointer to the previous save area at a fixed
>offset from the start of the area. The attack would have involved
>creating a bogus save area with register 14 pointing to the new code,
>then smashing the back pointer in the current save area.)
I don't think stacks growing upward help; remember that most exploits
in C involve on eof the unbounded copy routines and that those
overwrite the invocation record of the function calling sprintf/str* etc.
(Or one level deeper as on SPARC).
When the stack grows up, sprintf/str* will overwrite their own invocation
record/return address. So it's actually easier as there's no code executed
between the return from str*/sprintf , instead those function return
directly to the exploit code.
Casper
