[cgl_discussion] Buffer overflow

Makan Pourzandi (LMC) Makan.Pourzandi at ericsson.ca
Wed Apr 23 14:59:53 PDT 2003


Hi Bill, 

Well, I can't find anything more to say than what Mika already told you. 
Just to put my 2 cents, these requirements have been defined through the discussions among different NEPs. Therefore, hopefully they must reflect the needs of technical people from these NEPs to develop/implement/support the features that are demanded by the marketing people. 

I hope that we answered your question. 

regards, 
makan 

> -----Original Message-----
> From: Bill Roy [mailto:bill.roy at openwave.com]
> Sent: Tuesday, April 22, 2003 8:24 PM
> To: Makan Pourzandi (LMC); Paul Kierstead
> Cc: Stefano.Campadello at nokia.com; cgl_discussion at osdl.org
> Subject: RE: [cgl_discussion] Buffer overflow
> 
> 
> Hello CGLers:
> 
> My first post as an interested bystander who has been monitoring for a
> while.
> 
> I fully agree with the technical merit of this suggestion to raise the
> intrinsic security baseline of Linux distributions for operators.
> Non-executable stack should have been part of every baseline 
> architecture
> for decades.
> 
> But, I have a question; I hope you will forgive me if this is 
> a stupid one.
> Where would CGL get market validation for making an item like this one
> mandatory?  I have seen several completely reasonable technical points
> raised in this thread, but no input from, for example, 
> operators or SI's
> responsible for deploying and maintaining these service complexes to
> validate that this represents an item that will remove an obstacle to
> deployment of Linux in the operator.  Surely, there must be some
> counterbalance of market requirements against technical 
> goodness in arriving
> at requirements sets for CGL.
> 
> I have a similar observation for some of the mandatory 2.0 
> features in the
> Security section, for example the ones regarding secure syslog.  What
> deployment would not already have syslog on a secure 
> management network?
> 
> So, to restate my question: I see great technical discussions 
> going on here;
> where does market validation come from?
> 
> I sit on the Board of OMA and SyncML; we also struggle with 
> this question
> all the time.  I'm keenly interested in your thoughts on the 
> process in CGL.
> 
> My opinions, not Openwave's.
> 
> 
> Best regards,
> 
> 
> -br
> 
> 
> -----Original Message-----
> From: cgl_discussion-admin at lists.osdl.org
> [mailto:cgl_discussion-admin at lists.osdl.org]On Behalf Of 
> Makan Pourzandi
> (LMC)
> Sent: Tuesday, April 22, 2003 5:57 PM
> To: Paul Kierstead
> Cc: Stefano.Campadello at nokia.com; cgl_discussion at osdl.org
> Subject: Re: [cgl_discussion] Buffer overflow
> 
> 
> Hi all,
> 
> I believe that this is a requirement for level 8, possible suggestion:
> 
> 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 imlpement 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, data theft....
> 
> Security level 3
> 
> Priority 3
> 
> Maturity Exists
> 
> Category Mandatory
> 
> References
> 
> 1. http://www.openwall.com/linux/README, also LSM open wall module
> 
> 2. DTE reference ?
> 
> 3. Trusted Debian ?
> 
> 3. OpenBSD, TrustedBSD ;-) ??
> 
> comments?
> 
> regards,
> makan
> 
> 
> 
> Paul Kierstead wrote:
> 
> >on'I have been a bit absent recent; sorry about that. I will 
> be absent
> again
> >next week, but that is all good :)
> >
> >A non-executable stack is one of the very best defenses (in 
> theory, anyway)
> >to badly written software and -- lets face it -- most 
> software is badly
> >written. It comes pretty close to stopping all buffer 
> overflows (well,
> their
> >effects actually) in their tracks (there are a few exceptions). You
> software
> >may still suffer a denial of service (the stack is still 
> garbage), but no
> >intrusion should happen. This is awesome.
> >
> >Now the problem is that it still isn't mature. But I -- for 
> one -- would
> >love to see it at least mentioned somewhere as a future 
> consideration (upon
> >maturation). I suspect if we see the level of effort that goes into
> >exploiting Windows overflows applied to Linux, we might see 
> it mature a
> >little more quickly.
> >
> >That all being said, DTE (Domain Type Enforcement) can offer 
> many similar
> >benefits if applied well by strictly containing the damage.
> >
> >Or we could just write the software better :)
> >
> >
> >Paul Kierstead
> >Senior Security Researcher, Alcatel R&I Security Group
> >600 March Rd. Kanata, Ontario, Canada K2K 2E6
> >Tel: +1 613 784 4991 - EST
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: cgl_discussion-admin at lists.osdl.org
> >>[mailto:cgl_discussion-admin at lists.osdl.org] On Behalf Of
> >>Stefano.Campadello at nokia.com
> >>Sent: Tuesday, April 22, 2003 8:09 AM
> >>To: Makan.Pourzandi at ericsson.ca;
> >>mikukkon at miku-t21-linox.koti.nokia.com; cgl_discussion at osdl.org
> >>Subject: RE: [cgl_discussion] Buffer overflow
> >>
> >>
> >>So, what is your opinion? Should we add a requirement for 3.0
> >>or it is still premature now?
> >>
> >>Stefano
> >>
> >>
> >>
> >>>-----Original Message-----
> >>>From: ext Makan Pourzandi (LMC) 
> [mailto:Makan.Pourzandi at ericsson.ca]
> >>>Sent: 17 April, 2003 01:37
> >>>To: 'Mika Kukkonen'; cgl_discussion at osdl.org
> >>>Subject: RE: [cgl_discussion] Buffer overflow
> >>>
> >>>
> >>>Hi,
> >>>
> >>>My first reaction is to wait and see. Even if open bsd has a
> >>>very good reputation (I mean regarding security), we have to
> >>>wait for 1st May.
> >>>
> >>>Second, open bsd has always been more on advance at security
> >>>than linux. In best case, it will take some time before those
> >>>modification get into linux kernel. hopefully, this will not
> >>>generate too many flames ;-)
> >>>
> >>>last but not least, there are already linux kernel patches
> >>>regarding buffer overflows, one of the ones I know of is
> >>>
> >>>
> >>http://www.openwall.com/linux/README,  which implements
> >>Non-executable user stack area.  open wall is also
> >>implemented as a lsm module but at my knowledge not all
> >>functionality available by openwall is provided by the lsm module.
> >>
> >>regards,
> >>makan
> >>
> >>
> >>
> >>
> >>>-----Original Message-----
> >>>From: Mika Kukkonen [mailto:mikukkon at miku-t21-linox.koti.nokia.com]
> >>>Sent: Wednesday, April 16, 2003 10:58 AM
> >>>To: cgl_discussion at osdl.org
> >>>Subject: [cgl_discussion] Buffer overflow
> >>>
> >>>
> >>>An Anonymous Coward suggested to me that CGL should also
> >>>include something like this:
> >>>http://news.com.com/2100-1002-996584.html
> >>>
> >>>Now looking at the pace RedHat sends me up2date packages
> >>>that fix buffer overflows, I tend to agree, but I do think
> >>>this is one of those features that are _very_ hard to get
> >>>accepted by Linus.
> >>>
> >>>Any opinions?
> >>>
> >>>--MiKu
> >>>
> >>>_______________________________________________
> >>>cgl_discussion mailing list
> >>>cgl_discussion at lists.osdl.org
> >>>http://lists.osdl.org/mailman/listinfo/cgl_discussion
> >>>
> >>>
> >>>
> >>_______________________________________________
> >>cgl_discussion mailing list
> >>cgl_discussion at lists.osdl.org
> >>http://lists.osdl.org/mailman/listinfo/cgl_discussion
> >>
> >>_______________________________________________
> >>cgl_discussion mailing list
> >>cgl_discussion at lists.osdl.org
> >>http://lists.osdl.org/mailman/listinfo/cgl_discussion
> >>
> >>
> >
> >
> >
> 
> 
> _______________________________________________
> 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