[cgl_discussion] Re: Buffer overflow

[Greg KH]

On Mon, Apr 28, 2003 at 03:06:26PM -0400, Makan Pourzandi (LMC) wrote:
> Hi all, 
> 
> There are already several valid open source projects regarding buffer
> overflow, also given the necessity of protecting the system against
> the numerous buffer overflows. I propose considering the requirement
> for CGL 2.0, it means as for section 6 (For example, Pax mechanisms
> are already part of trusted debian, openbsd (ok, not linux, I know
> :-)), and several others .... ).   

Um, I think the fact that you admit the features are not part of Linux
today, should not place such a high priority or maturity level of these
features.  Fact is, they all have their drawbacks and reasons for not
being mainline:

> 1.	PaX kernel Patch: "The goal of the PaX project is to research
> various defense mechanisms against the exploitation of software bugs
> that give an attacker arbitrary read/write access to the attacked
> task's address space. This class of bugs contains among others various
> forms of buffer overflow bugs (be they stack or heap based), user
> supplied format string bugs, etc."  (http://pageexec.virtualave.net/ )

This slows things down.  It also breaks existing programs that currently
ran just fine.  These are both reasons it's not more widly used.

> 2.	StackGuard is an enhancement to GCC that generates programs
> robust against stack-smashing attacks.
> http://www.immunix.org/stackguard.html  

This is for a _very_ old version of gcc.  One that no distro supports
anymore.  The developers have been promising for the past two years a
newer version against gcc-current, but have shown no working code.  So
this really isn't a viable options.

> 3.	ProPolice is an enhancement to GCC that generates programs
> robust against stack-smashing attacks.
> http://www.trl.ibm.com/projects/security/ssp/ 

This is better, and is what openbsd uses.  But I don't know of any Linux
distros that have tried to use this to build all of their packages and
test with them.  The developers seem to be focusing their efforts on the
various BSDs, which is great, but can't be considered a Mature
technology for Linux today.

In short, please modify the priorities and maturity levels of this
entry, if you choose to add it to the CGL spec.

thanks,

greg k-h