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]
Message-ID: <A3259AF0-CDBD-11D7-8FC3-000393B972BA@strong-box.net>
Date: Wed, 13 Aug 2003 11:40:40 -0700
From: Craig Pratt <craig@...ong-box.net>
To: "Eygene A. Ryabinkin" <rea@....mbslab.kiae.ru>
Subject: Re: Buffer overflow prevention



On Wednesday, Aug 13, 2003, at 03:28 US/Pacific, Eygene A. Ryabinkin 
wrote:
>   Hi!
>  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.
>
>  Preliminary: I'm talking about Intel x86 architecture, but maybe it 
> will be
> applicable to others as well.
>
>  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:
>  1) Local variables and return address will be physically (by means of 
> CPU)
>     divided and it will not be possible to touch the return address by
>     overflowing local buffer.
>  2) The procedure introduces only one extra register -- GS, since EBP 
> is
> 		very often used for the stack frame.
> Of course, this two segments can be made non-executable, just in case.

It's definitely good to be thinking of novel approaches to securing 
code. Machines in the old days used to have memory partitioned in 
similar fashions. But realize that overwriting return addresses via 
stack trashing is only one way a program can be compromised.

C++ programs, for instance, have vtables, 'this' pointers, and all 
sorts of other fun stuff that can be tinkered with - not to mention the 
heap.

Approaches that involve partitioning executable code and data are 
probably the easiest route. It becomes a major challenge to do 
something interesting with return address manipulation when the memory 
map is setup with execute-only in one range (for the code) and 
non-executable (for stack & heap) in another. If you can't inject a 
return address to the code of your choosing, than what's the point?

Dealing with dynamic code gets tricky (dynamic libs, Java, CLR, and 
interpreters) in this environment. But it's quite do-able.

>  What we need to implement the idea: first, rewrite kernel to organise 
> two
> segments for every process and to place proper values into the segment
> registers upon the program startup. Second, rewrite the compiler to 
> support
> the new scheme of local variables addresation. So, the changes are 
> minimal,
> in some sence.
>
>  As I said, I hardly need your criticism, suggestions, etc. of any 
> type.
> 	rea

What fun is that? ;^)

Craig

--
Craig Pratt
Strongbox Network Services Inc.
mailto:craig .AT. strong-box.net


-- 
This message checked for dangerous content by MailScanner on StrongBox.




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ