Re: Buffer overflow prevention

[Theo de Raadt <deraadt () cvs openbsd org>]

> > Also, you can use chpax, and turn on a non-executable stack, and with a small
> > amount of voodoo (in tracking down the binarys and .so's that need the stack,
> > wich typically is only a single binary or .so file, wich you can find with
> > ptrace, strace, or ltrace) you can have all of your stuff run with a
> > non-executeable stack, thus making stack smashing impossible. Nothing can
> > execute off your stack so a malicous person can override all the addresses he
> > wants, his code cant run off your stack.
> It's been proved many times that non-executable stack adds NO security at
> all.
> Every single class of vulnerabilities exploitable with executable stack
> can be also exploited with non-executable stack.
> See for example our article (http://www.phrack.org/show.php?p=56&a=5)
> which shows how to bypass a stack protector even with a non-executable
> stack.
>
> What we're discussing here is an internal structures and data protecting.
> IMHO the ProPolice (http://www.research.ibm.com/trl/projects/security/ssp/),
> is the best protection in this kind, even comparing to "two stack"
> approach.
> Beside that it's an existing, well tested and wide used (for example
> OpenBSD uses it by default now).
> I see no real reason why the major Linux companies are not using it for
> its products.

I believe the best protection (at this time) is to combine ProPolice with
a W^X technology.

W^X is more than just stack protection.  It means that all pages that
are writeable are also marked as not executable.  At least, it means
this is how the system by default operates, until some process asks
for something that has both write and execute permission.

On some architectures W^X is easy, since the native architecture has a
execute-permitted bit per page (sparc, sparc64, alpha, hppa, m88k).
On other architectures, it is difficult and various hacks have to be
done to make it work (i386, powerpc).  On other architectures it is
just impossible (vax, m68k, mips, arm).

W^X is more than just stack protection.  It means that the data segments
are not executable.  Nor is malloc'd memory.

But W^X goes even further than this, since we consinder it a principle
that objects which are used should be protected as much as possible.

For instance, we've gone further and also modified ld.so so that the
PLT and GOT tables follow the W^X principle as well.  Whenever ld.so
has to make modifications to these tables, it must add W permission,
modify them, and then remove W permission again.  They continue as
before, but are not vulnerable to modification.

Why does the linker create .ctor and .dtor segments that are writeble?
These have been fixed so that they cannot be modified.

We've modified atexit() too.  It's table of exit functions maintained
by this is no longer writeable by a regular process.  The atexit() API
maintains write-protected pages of pointers to exit functions.

And there are other applications of this principle.

All of this serves to make processes more robust in the face of a bug.

(My main point here is that stack protection by itself might be less
than useful, but add together all the other details above, and you
have created significant constraints for a person trying to take a
regular bug and escalate it towards exploitability)