Apology re: Buffer Overflow Prevention

Theo de Raadt wrote:
> I believe the best protection (at this time) is to combine ProPolice with
> a W^X technology.

Solaris 2.6 and above also support a kernel variable which can be set
via /etc/system called "noexec_user_stack", which can make the stack for
userland processes non-executable by default. Note that this behavior
is the default for 64-bit binaries in Solaris 7, 8, and 9, and this
kernel variable forces the behavior for 32-bit binaries. I run all
sorts of odd software and have never had an issue with having this
always turned on for all of my systems.

On Thu, Aug 14, 2003 at 10:17:29PM +0300, Timo Sirainen wrote:
> AFAIK all those combined do bring real security against generic exploits.

"Real security" is not the word.

PaX / Propolice / W^X / non-exec stacks don't solve bugs. What they do is
to _abort_ execution of a process when it behaves abnormally.

So instead of giving attackers the opportunity to run arbitrary code, you
only give them the ability to cause a denial of service.

This kind of protection should be coupled with tools that automatically
restart daemons when they crash (ex: daemontools and monit) to actually keep
the service running when under attack. Still, all of this is a couple of
unreliable band-aids.

--
__ /*- Frank DENIS (Jedi/Sector One) <j@42-Networks.Com> -*\ __
\ '/ <a href="http://www.PureFTPd.Org/"> Secure FTP Server </a> \' /
\/ <a href="http://www.Jedi.Claranet.Fr/"> Misc. free software </a> \/

> ProPolice is not magical, though. There are plenty of cases where it is
> totally inefficient. To illustrate a very common one :
>
[snip oflow of 5-byte buffer]

This particular case ``works'' because, by design, propolice will not
attempt to protect structures smaller than 16 bytes.

This can be changed by a simple gcc recompilation... and it's probably
worth doing.

Miod

On Thu, 14 Aug 2003 13:37:06 -0600
Theo de Raadt <deraadt@cvs.openbsd.org> wrote:

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

yes, and ?

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

Ok so it really restrict a lot the possibility of arbitrary code execution
when we have vuln_function(); exit(); (since atexit / .dtors are executed
after exit() or when main() return)....
Well, I just see such vulnerability scenario in some vuln.c made for fun...

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

Well, all these protection add a layer of security, but it s still
bypassable in 90% of bug.

Let's take concret example. So, for me, the last "big" vulnerability
release were :

- wuftpd remote shell bug
- sendmail remote shell bug
- openssl remote shell bug

I won't covert more issue since we have here a .bss overflow, a
heap overflow, and a stack off by one bug.

Before continuing, W^X protection don't block exploitation of
buffer overflow, they block execution of code on data segment such
as stack/heap... ... execution of code is still possible by returning
into GOT / PLT / LIB....

so wuftpd permit to overwrite in some case the lsb of the saved_ebp.
I don't know much about propolice (I just heard about some method
to bypass it;), but lets say that it will block the saved_ebp
overwriting... You still can overwrite local variable in other
function, and this lead to being able to upload file not only
as user anonymous, but as root.... so in this vuln there
is a way to cheat. This way isn't generic at all, and some
can argue it's very special case, but I believe that such
a case can be found in most of vuln exploitation. We just
usually to think about it because overwriting a saved_ebp
appear more ... erhm ... common way. With this we then can
overwrite /bin/ls or any file in ftp that can then lead to
arbitrary code execution...

For sendmail hole, we can overwrite a function pointer, so
we can use ret2libc to mprotect memory and execute shell
(seems the easier way)...

For openssl code we can overwrite function pointer and use
ret2libc too...

In all these case exploitation can be done using "targetless"
method, so we don't care about what exact version the remote
is using...

Finnally openbsd protection can all be defeat, and I am sure
that in the futur, exploit coders will found some tricks and
will still bypass your protection...


To finish, PaX ASLR (+grsec) is actually the best protection
even written against buffer overflow, even if it is here again
bypassable in some way... just take a look at phrack article,
or look this : http://mapage.noos.fr/hrchallenge/bpax.tgz

And I am not talking here about partial overwriting of pointer
or using a bug to create infoleak (read the two good phrack
article who explain how to do in the two most common buffer overflow :
the stack overflow and the heap overflow).

To conclude, all your protection are a good new security layer,
but it just stay one security layer, not a full protection...
And each time vulnerability will be found in OpenBSD running server,
openbsd will be affected as well....


Best regards,

Nicolas Brito

I believe that Mr. Raadt meant PAX by W^X.
We all enjoy ascii art but I wanted to note that renaming somebody
elses work is not so ethical.

so for the real thing please consider checking:
http://pageexec.virtualave.net/

my linux box have 0 remotely exploitable vulnerabilities in its default
install since the begining of time and space. thanks to segmentation, ASLR
from the PAX project.

Thanks,
- noir

-----Original Message-----
From: Theo de Raadt [mailto:deraadt@cvs.openbsd.org]
Sent: Thursday, August 14, 2003 12:37 PM
To: Mariusz Woloszyn
Subject: Re: Buffer overflow prevention

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

Hi!

> So the best protection is probably Propolice + non exec stack + write xor
> executable pages. Oh, surprise, this is just how OpenBSD works.

PaX is more strict in its W^R enforcement than OpenBSD.

> This is still not a magical protection against everything. A vulnerable
> application can still behave abnormally after an overflow. But this couple
> makes injection + execution of arbitrary code way more tricky.

Right there is no silver bullet. The only thing you can hope for is to raise
the bar high enough that noone can jump over it.

> The only way to sleep quietly is still to audit the code at the first place.

The only way to sleep quietly in fact is to feed your computer to a shredder.

Auditing code alone will not provide much security. In fact, it will lead to a
false sense of security. The problem is that a modern UNIX system is that it
contains millions of lines of code. Auditing this amount of code is simply
impossible. Furthermore, auditors are humans. Humans make mistakes, not only
when they are programmers, but also when they are auditors. So audited code
will still contain security bugs.

In fact, the amount of security in OpenBSD is only slightly less horrible than
that of most *NIX operating systems (which includes Adamantix for that matter).

Groetjes,
Peter Busser
--
The Adamantix Project
Taking trustworthy software out of the labs, and into the real world
http://www.adamantix.org/