Security Basics mailing list archives
RE: considerations about exploits tricks
From: "Craig Wright" <Craig.Wright () bdo com au>
Date: Tue, 6 Nov 2007 10:15:15 +1100
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.
Current thread:
- considerations about exploits tricks opexoc (Nov 04)
- Re: considerations about exploits tricks PCSC Information Services (Nov 05)
- <Possible follow-ups>
- Re: considerations about exploits tricks jfvanmeter (Nov 05)
- Re: considerations about exploits tricks krymson (Nov 05)
- RE: considerations about exploits tricks Craig Wright (Nov 05)
- Re: RE: considerations about exploits tricks opexoc (Nov 08)