[cgl_discussion] Re: Buffer overflow

Fleischer, Julie N julie.n.fleischer at intel.com
Mon Apr 28 15:39:24 PDT 2003


This looks good.  Just a couple of proposals on the wording below to call
out the mechanisms and which projects implement them.

7.2.2	Support for buffer overflows protection mechanisms

Description: 	
One of the major sources of vulnerability on Linux is buffer overflows.
Currently, several mechanisms exist to protect against these buffer
overflows through the OS: non-executable stack, kernel stack randomization,
userland stack randomization, compiling code robust against stack smashing.
At least one of these mechanisms must be supported in order to protect the
system against buffer overflows.

(snip)

References:	
1.	PaX kernel Patch: PaX contains a collection of programs that defend
against vulnerabilities such as buffer overflows.  It contains programs for
non-executable pages, kernel stack randomization, userland stack
randomization, and others. http://pageexec.virtualave.net/

(snip)

**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 3:20 PM
> To: 'Fleischer, Julie N'
> Cc: cgl_discussion at lists.osdl.org
> Subject: RE: [cgl_discussion] Re: Buffer overflow
> 
> 
> Hi, 
> 
> 
> Here we go with new proposal: 
> 
> =================================================================
> 7.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... At least one of 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: 			2
> 
> 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.	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: Fleischer, Julie N [mailto:julie.n.fleischer at intel.com]
> > Sent: Monday, April 28, 2003 4:26 PM
> > To: Makan Pourzandi (LMC)
> > Cc: cgl_discussion at lists.osdl.org
> > Subject: RE: [cgl_discussion] Re: Buffer overflow
> > 
> > 
> > > 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