[cgl_discussion] Re: Buffer overflow

Makan Pourzandi (LMC) Makan.Pourzandi at ericsson.ca
Mon Apr 28 14:02:53 PDT 2003


> -----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
......
> 
> Some questions:
> - Were we also going to add a reference to Openwall -
> http://www.openwall.com/linux for non-executable user stack area?

from what Greg told us and what I read (which is far away to be a complete lecture on the open wall), if I understood well, there are not many chances that this patch will be accepted to the linux main line and we have already several other valid references. therefore, I suggest not adding this reference to the doc. Any comments on open wall? 

> - Were we going to add a link about randomizing the stack from
> http://news.com.com/2100-1002-996584.html?

>From what I read, the article refers to open bsd and not linux. 

> - 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

No, I bleieve that we're going to change it as you suggested. 

> 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