[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
>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.
> 3. ProPolice is an enhancement to GCC that generates
> programs robust
> against stack-smashing attacks.
> > -----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
More information about the cgl_discussion