bugtraq - Re: Buffer overflow prevention

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 13 Aug 2003 11:12:39 -0700
From: Crispin Cowan <crispin@...unix.com>
To: "Eygene A. Ryabinkin" <rea@....mbslab.kiae.ru>
Subject: Re: Buffer overflow prevention


Eygene A. Ryabinkin wrote:

> I have an idea on buffer overflow prevention. I doubt that it's new, but I
>haven't seen an implementation of it in any freely distributable Un*x system.
>So, I hardly need your comments on it.
>...
> The idea itself: all (correct me if I'm wrong) buffer overflows are based on
>the fact that we're using the stack, referenced by SS:ESP pair, both for
>procedure return address and for local variables. It seems to me, that would we
>have two stacks -- one for real stack and one for variables -- it will solve
>a bunch of problems. So, my suggestion: let us organise two segments: one for
>normal stack, growing downwards, referenced by SS:ESP pair and the second one,
>for local variables, referenced by GS:EBP pair, with either upwards or
>downwards growing. Now, if we use first segment for passing variables and
>procedure return addresses (normal stack usage), and second segment only for
>local procedure variables, we will have the following advantages:
>
This is approximately what StackShield 
<http://www.angelfire.com/sk/stackshield/info.html> does. However, it 
does not appear to have been maintained since 2000.

Crispin

-- 
Crispin Cowan, Ph.D.           http://immunix.com/~crispin/
Chief Scientist, Immunix       http://immunix.com
            http://www.immunix.com/shop/