[Top] [All Lists]

Re: CHALLENGE: forbidding processes to smash their stack

To: "Biscondi, Philippe" <>,
Subject: Re: CHALLENGE: forbidding processes to smash their stack
From: Matthias Heidbrink <>
Date: Thu, 11 May 2000 13:58:18 +0200
In-reply-to: <>; from on Thu, May 11, 2000 at 12:30:11PM +0200
References: <>
Hi Philippe,

On Thu, May 11, 2000 at 12:30:11PM +0200, Biscondi, Philippe wrote:
> The problem, also known as buffer overflows/overruns, have been responsible
> for hundreds of security holes in software yielding local/remote root
> shells.

There are two different approaches, hardware and software. 

If you ask for hardware, I am only able to say something about i386 because 
I don't know other architectures good enough. 
On Intel some the problem of data overwriting the stack can be solved easily: 
It should be possible to use separate memory segments for code, data and 
stack. That was how 16-bit systems like DOS worked (although without write 
protection), but all 32bit operating systems which I know  of map the 
different segments to the same address space because that's less compilicated.

There is also a software approach: Use programming languages from the Pascal 
family which have strong type checking, require using dangerous pointer 
operations very seldom and offer Range Checking (for strings and arrays), 
Overflow Checking (e.g. for arithmetical calculations) and so on. 
There are theoretical reasons why programs in "hacker" languages like C/C++
simply cannot be 100% reliable. But I cannot explain it here, whole books 
could be written about it. E. g. Ada is a lange monster like C++, but the 
language definition and compiler behaviour is defined much more preceisely and 
noone would dare calling a compiler an ADA compiler before it fulfills tests
that it conforms to the language. That's a base for construction solid 
software. As far as I know, still no C++ compiler exists that fulfills the 
standard, so that's nothing you can depend on. Maybe it's even impossible to 
write a 100% standard-conformant C++ compiler because the language is so
complicated and probably ambiguous.

Ciao, Matthias
Matthias Heidbrink     E-Mail: 
Bundesratufer 12  
10555 Berlin, Germany         
Tel. +49-30-8536361   (at work;

<Prev in Thread] Current Thread [Next in Thread>