> >> There's an even simpler fix, with the compiler just pushing 0 on entry
> >> to all functions, and on exit it pops it off and aborts if it is
> >> non-zero.
>
> > I have a preliminary implementation of this for egcs 1.03a. I tested
> > the overhead on gzip - it looks pretty good. I use the following
> > pattern which ensures that the branch is predicted non-taken:
>
> Are you aware of Stackguard. They have a modified gcc that does
> more or less this, and are in the process of building a version
> of Red Hat 5.1 that uses it.
The new StackGuard has another enhancement: not all string functions are
null-terminated. For instance, gets() terminates on CR, LF, or EOF (-1), but
reads (and copies) through nulls. The new StackGuard uses a "terminator"
canary value that is a combination of CR, -1, LF, and Null, which should
frustrate most string operations. The down-side is that this is slightly
slower than the "compare with 0" test that can be used if you just have a
Null canary word.
> It was already mentioned here:
>
> http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/
The new StackGuard (ver. 1.1) is not yet described on the web page. The
descriptions will be updated and an announcement made in a few days when we
release the re-built RH 5.1 packages.
Credits: the "null" hack was first proposed (to my knowledge) by der mouse
in Bugtraq about 6 months ago. The terminator hack was invented by me in May
1998, when an attendee at the Oakland Security Conference pointed out that
gets() and friends aren't null-terminated.
Crispin
-----
Crispin Cowan, Research Assistant Professor of Computer Science, OGI
StackGuard: protect your software against Stack Smashing Attack
http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/
Support Justice: Boycott Windows 98
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html