Bugtraq mailing list archives
Re: Smashing the Stack: prevention?
From: ryde () TRIPNET SE (Daniel Ryde)
Date: Mon, 28 Apr 1997 14:26:52 +0200
On Sun, 27 Apr 1997, nate wrote:
1. 'you gotta change the code'
Yes, of course this it the longterm solution. sed 's/gets/fgets/g' :)
2. 'hmm. what if you change the compiler?'
This is a good for short term fixes, _IF_ you make it a switch. for example: "gcc --bound-check ..." (Hmm, maby this is already implemented). If somebody screams, buffer overflow in... then just recompile, and use it until the problem is fixed. And/or you have the ability to recompile known security risk programs permanently (aka sendmail, or other daemon/suid) just in case.
3. 'ok, what about the CPU/OS kernel stack exec permission?'
Another long term fix, yes. Meanwhile, make it an kernel option. Code should remain in "code segment", and data should remain in "data/stack segment" [my opinion]. Some processors rely on this, as they already have physically separated code and data memory. Hardware is constructed with this philosophy in mind (cache, branch prediction, and so on). It's like self modifying code... it's ugly, but fun sometimes, though it definatley destroys more then it gains. Real selfmodyfying artificial intelligent code might be reallity decades in the future, but not now. When that time is, I guess we would have other things to worry about. [sorry for the off-topic :] If the programmers follows this philosophy too, then it should'nt be any problem removing exec on data/stack. You could even make the code-segment read-only, and viola, now we only have file-writing/creation/linking, trojans, viruses, denial of service attacs and air pollution to worry about, almost... -|- Daniel Ryde, Tripnet AB Tel: +46 31 7252500 `-' System Administrator Fax: +46 31 7252501
Current thread:
- Digital UNIX/Irix mesg problem, (continued)
- Digital UNIX/Irix mesg problem Tom Leffingwell (Apr 29)
- Re: Digital UNIX/Irix mesg problem John Sheehy (Apr 29)
- Access control on W3C httpd server Peter Lord (Apr 30)
- vulnerabilities in kerberos David Sacerdote (Apr 29)
- Sun Security Bulletin #00139 Sun Security Coordination Team (Apr 29)
- SMASHING THE STACK: PREVENTION? massimo at vnet.ibm.com (Apr 28)
- Re: SMASHING THE STACK: PREVENTION? Alex Belits (Apr 28)
- Re: SMASHING THE STACK: PREVENTION? Thomas H. Ptacek (Apr 29)
- Re: Smashing the Stack: prevention? Tim Newsham (Apr 27)
- Re: Smashing the Stack: prevention? Joe Zbiciak (Apr 28)
- Re: Smashing the Stack: prevention? Daniel Ryde (Apr 28)
- xlock clarification.... David Hedley (Apr 28)
- Re: Smashing the Stack: prevention? Steve Coleman - SEWP (Apr 28)
- Re: Smashing the Stack: prevention? Alexander Snarskii (Apr 28)
- Re: Smashing the Stack: prevention? Michael Shields (Apr 28)
- Re: Smashing the Stack: prevention? Theo de Raadt (Apr 28)
- Re: Smashing the Stack: prevention? Shawn Instenes (Apr 29)
- Re: Smashing the Stack: prevention? J.R.Valverde (Apr 28)
- Re: Smashing the Stack: prevention? Randal Schwartz (Apr 28)
- Re: Smashing the Stack: prevention? Thomas H. Ptacek (Apr 29)
- Re: Smashing the Stack: prevention? J.R.Valverde (Apr 29)