[cgl_discussion] Re: Buffer overflow
Makan Pourzandi (LMC)
Makan.Pourzandi at ericsson.ca
Tue Apr 29 07:33:40 PDT 2003
Hi Julie,
Added your modifications.
makan
> -----Original Message-----
> From: Fleischer, Julie N [mailto:julie.n.fleischer at intel.com]
> Sent: Monday, April 28, 2003 6:39 PM
> To: Makan Pourzandi (LMC)
> Cc: cgl_discussion at lists.osdl.org
> Subject: RE: [cgl_discussion] Re: Buffer overflow
>
>
> 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