RE: considerations about exploits tricks

["Craig Wright" <Craig.Wright () bdo com au>]

Well actually, you can attempt to fix the stack for a start. You are
correct that fixing the multitude of programmes and programmers is
unlikely and that new ones are "born" every day.

We should all know that code "usually" resides in a R/O text area at the
start of the program memory. In an idea world our programs will not
execute any instructions off of the data stack.

In the case of hardware that supports it, software can be integrated to
stop many of these attacks. On AMD64 and Pentium-4 (and newer) CPU's
there is what is called an NX bit. The Linux kernel has had support for
the NX bit functionality since 2.6.8. In solaris and HP-UX there are
kernel switches for this behaviour on RISC chips (eg noexec_user_stack=1
in /etc/system on Solaris).

OpenBSD has W^X (3.4 up) and the grsecurity (grsecurity.org) PaX patches
include stack-protection from the Admantix Linux Project. Redhat has
"Exec Shield" for this. 

With the Risc systems (solaris, HPUX etc), stack protection prevents
executing code off stack pages. This still does not stop heap attacks -
but these are another issue.

W^X and PaX (with NX) marks all writable-pages as non-executable - even
the heap area and other data areas - not just the stack. The issues come
as many high level languages (ie JAVA, JSP etc) execute runtime code out
of the heap. Thus these can break Java.

So this is a functionality issue for a start. Many systems (eg Internet
DNS) do not need the extended functionality provided by Java and other
high level languages. In this case - there is a good case to disable
code from running out of the data areas, stack and heap. On the other
hand, Users want to browse the web etc and as such they want this added
feature (ie no heap protection).

Alternatively there is another option.

There are complier-based solutions. Adding a "Canary" between the frame
pointer and return address in order to create code that is resistant to
buffer overflows. In this, any buffer overflow exploit that overflows
the data area and writes downward to the return address pointer will
also overwrite the canary value (I will ignore format string attacks for
this as this make it a little too complex). 

In the normal course of program execution, the program will check the
canary value. If this has been altered (ie buffer overflow exploit or
error) the program aborts rather than returning the memory address given
by the return address pointer. This adds an overhead of about 10% to the
system, but makes many classical buffer overflows unable to be executed.
GCC has this option built in (-fstack-protector & -fstack-protector-all)
though they are rarely used. I believe that Novell - from OpenSUSE 10.3
is building this in though I have not tried to break this myself. 

So to end - there are a number of options. Some work very well, but all
have a cost. This may be an increase performance hit and it may be no
Java, but it is possible. So for the original question, PAX helps, but
it breaks Java and other pretty user toys.

Regards,
Craig Wright (GSE-Compliance)

PS Self modifying code is an issue and does not always follow
conventions, but this is a separate issues and is  not what most code
does.

-----Orig. Message-----
.From: listbounce () securityfocus com
[mailto:listbounce () securityfocus com] 
.Sent: Tuesday, 6 November 2007 8:39 AM
.To: security-basics () securityfocus com
.Subject: Re: considerations about exploits tricks

Can we defeat overflows? Well, sure, but one (or both) of three things
need to happen. First, you need to teach every software programmer and
engineer how to properly bound their code. Second, you need to write a
program that will inspect and intelligently decide whether code in
memory needs to be bounded. Good luck with that. Or three, randomize
memory so much that an attacker can't predict it. 

This last piece is where a lot of progress has been made, but who is to
say we even know about all the possible overflows that may happen? In 3
years, will some new technique be discovered? Will some new programming
or technology recover old overflows we thought were fixed?

Let alone everything else about security such as the people as others
have already mentioned. We can't win the whole battle against attackers,
but we can be successful in our defenses and risk management. And the OS
dramatically changes often, due to economics and human technological
progress...which can usher in whole new classes of vulns...

If you want to think otherwise, I will point to teen pregnancy, murder,
and drug use as other evils, and ask you why we've not "solved" these
issues to the point that they are eradicated and the battle won...


<- snip ->
Hello,

I wonder about security holes which are still present in our OS, which
let attackers take over control. I have heard about PAX system,
ProPolice and other, which in consolidation should well defend system
against attacks like buffer overflow. Is it not enough? Can't we really
win the battle against buffer overflow and heap overflow?

opexoc

Craig Wright
Manager of Information Systems

Direct : +61 2 9286 5497
Craig.Wright () bdo com au
+61 417 683 914

BDO Kendalls (NSW)
Level 19, 2 Market Street Sydney NSW 2000
GPO BOX 2551 Sydney NSW 2001
Fax +61 2 9993 9497
www.bdo.com.au

Liability limited by a scheme approved under Professional Standards Legislation in respect of matters arising within 
those States and Territories of Australia where such legislation exists.

The information in this email and any attachments is confidential.  If you are not the named addressee you must not 
read, print, copy, distribute, or use in any way this transmission or any information it contains.  If you have 
received this message in error, please notify the sender by return email, destroy all copies and delete it from your 
system. 

Any views expressed in this message are those of the individual sender and not necessarily endorsed by BDO Kendalls.  
You may not rely on this message as advice unless subsequently confirmed by fax or letter signed by a Partner or 
Director of BDO Kendalls.  It is your responsibility to scan this communication and any files attached for computer 
viruses and other defects.  BDO Kendalls does not accept liability for any loss or damage however caused which may 
result from this communication or any files attached.  A full version of the BDO Kendalls disclaimer, and our Privacy 
statement, can be found on the BDO Kendalls website at http://www.bdo.com.au or by emailing administrator () bdo com au.

BDO Kendalls is a national association of separate partnerships and entities.