[cgl_discussion] Buffer overflow

Tue Apr 22 17:24:27 PDT 2003

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