lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <200308141937.h7EJb6hd021598@cvs.openbsd.org>
Date: Thu, 14 Aug 2003 13:37:06 -0600
From: Theo de Raadt <deraadt@....openbsd.org>
To: Mariusz Woloszyn <emsi@...rtners.pl>
Subject: Re: Buffer overflow prevention


> > 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)


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ