[cgl_discussion] Re: Buffer overflow

Fleischer, Julie N julie.n.fleischer at intel.com
Mon Apr 28 13:26:09 PDT 2003


> New proposition: 
> 
> ===============================================================
> 6.2.2	Support for buffer overflows protection mechanisms
> 
> Description: 	
> One of the major sources of vulnerability on Linux is buffer 
> overflows. For time being, several projects exist that 
> implement the protection against these buffer overflows 
> through the OS: non-executable stack, randomizing the place a 
> program is loaded into memory... These mechanisms must be 
> supported in order to protect the system against buffer overflows.
> 
> Threats mitigated: 
> These mechanisms mitigate the possible buffer overflows. This 
> mitigates the theft of root privileges and unauthorized access. 
> 
> Security level: 		3
> 
> Priority: 			1
> 
> Maturity:			Usable 
> 
> Category: 			Configurable 
> 
> References:	
> 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/ )
> 2.	StackGuard is an enhancement to GCC that generates 
> programs robust against stack-smashing attacks.  
http://www.immunix.org/stackguard.html  
>3.	ProPolice is an enhancement to GCC that generates programs robust
against stack-smashing attacks.
http://www.trl.ibm.com/projects/security/ssp/ 

Some questions:
- Were we also going to add a reference to Openwall -
http://www.openwall.com/linux for non-executable user stack area?
- Were we going to add a link about randomizing the stack from
http://news.com.com/2100-1002-996584.html?
- Along those lines, I'm wondering if we want to change the last sentence of
the first paragraph to something more like "At least one [or maybe none?] to
all of these mechanisms need to be supported in order to protect the system
against buffer overflows."  That way, the implementor doesn't need to
support/implement all references.  Either that or we could move this to
priority 3 where the ambiguity is still okay.

- Julie

**These views are not necessarily those of my employer.**


> -----Original Message-----
> From: Makan Pourzandi (LMC) [mailto:Makan.Pourzandi at ericsson.ca]
> Sent: Monday, April 28, 2003 12:06 PM
> To: 'Mika Kukkonen'; Greg KH
> Cc: cgl_discussion at lists.osdl.org; Campadello Stefano
> Subject: RE: [cgl_discussion] Re: Buffer overflow
> 
> 
> 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 .... ).   
> 
> New proposition: 
> 
> ===============================================================
> 6.2.2	Support for buffer overflows protection mechanisms
> 
> Description: 	
> One of the major sources of vulnerability on Linux is buffer 
> overflows. For time being, several projects exist that 
> implement the protection against these buffer overflows 
> through the OS: non-executable stack, randomizing the place a 
> program is loaded into memory... These mechanisms must be 
> supported in order to protect the system against buffer overflows.
> 
> Threats mitigated: 
> These mechanisms mitigate the possible buffer overflows. This 
> mitigates the theft of root privileges and unauthorized access. 
> 
> Security level: 		3
> 
> Priority: 			1
> 
> Maturity:			Usable 
> 
> Category: 			Configurable 
> 
> References:	
> 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/ )
> 2.	StackGuard is an enhancement to GCC that generates 
> programs robust against stack-smashing attacks.  
http://www.immunix.org/stackguard.html  
3.	ProPolice is an enhancement to GCC that generates programs robust
against stack-smashing attacks.
http://www.trl.ibm.com/projects/security/ssp/ 

> -----Original Message-----
> From: Mika Kukkonen [mailto:mika at osdl.org]
> Sent: Thursday, April 24, 2003 12:25 PM
> To: Greg KH
> Cc: cgl_discussion at lists.osdl.org; Makan Pourzandi (LMC); Campadello
> Stefano
> Subject: Re: [cgl_discussion] Re: Buffer overflow
> 
> 
> On Thu, 2003-04-24 at 08:57, Greg KH wrote:
> > On Thu, Apr 24, 2003 at 08:22:05AM -0700, Mika Kukkonen wrote:
> > > On Wed, 2003-04-23 at 17:23, Greg KH wrote:
> > > (...)
> > > > And there's things like the StackGuard or ProPolice gcc 
> patches that
> > > > might be better to point people at.  However, that's 
> not a kernel
> > > > patch/feature, so would not fall under the CGL spec :)
> (...)
> > Ok then, why not specify a specific version of gcc (like the above
> > mentioned versions) if you all really want to worry about 
> something like
> > this?
> 
> AFAIK some distros already ship with their own modified 
> version of gcc same
> way as they ship with their own modified version of Linux 
> kernel, and from
> CGL viewpoint this is OK (we do aim to get 99% of our 
> features into mainline
> kernel/gcc, but sometimes that takes a loooong time, or never 
> because of
> non-technical issues).
> 
> So if our security people feel like adding a generic requirement like
> "CGL C-complier should provide the option to compile applications with
> StackGuard/ProPolice", I do not have an issue with it.
> 
> But I do think this kind of additional checking (which always 
> comes with
> price tag on performance) should be optional, with the actual 
> decision of
> whether to use it or not left to the distros and their 
> customers. Hence
> the word "optional" in my example above.
> 
> Makan/Stefano, any thoughts?
> 
> --MiKu
> 
> 
_______________________________________________
cgl_discussion mailing list
cgl_discussion at lists.osdl.org
http://lists.osdl.org/mailman/listinfo/cgl_discussion



More information about the cgl_discussion mailing list