Message-ID: <20030816151422.6f8c0c1a.unixlabs@noos.fr>
Date: Sat, 16 Aug 2003 15:14:22 +0200
From: sauron <unixlabs@...s.fr>
To: bugtraq@...urityfocus.com
Subject: Re: Buffer overflow prevention


On Thu, 14 Aug 2003 13:37:06 -0600
Theo de Raadt <deraadt@....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

Powered by blists - more mailing lists