Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Jun 2002 03:38:23 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Igor Sysoev <is@rambler-co.ru>
Cc:        arch@FreeBSD.ORG
Subject:   Re: Time to make the stack non-executable?
Message-ID:  <3D1EDF9F.D10072FC@mindspring.com>
References:  <Pine.BSF.4.21.0206301349360.83331-100000@is>

next in thread | previous in thread | raw e-mail | index | archive | help
Igor Sysoev wrote:
> On Sat, 29 Jun 2002, Terry Lambert wrote:
> > Doug Barton wrote:
> > > Subject: We're famous
> > >http://story.news.yahoo.com/news?tmpl=story&ncid=70&e=2&cid=70&u=/cn/20020629/tc_cn/940585
> 
> Of course non-executable stack is good idea but
> Apache's chunked exploit does not execute any code on stack.
> Code runs in Apache malloc()ed BUFF structure.

We are talking about the general case, not a specific case;
not having seen the worm code, I can't speak for whether the
trigger itself needed the stack, or not.

At some point, you get a critical mass large enough, and you
end up with enough people running your OS with non-updated
server applications.  You become another Microsoft, where the
failure isn't so often that there isn't a patch, as it is
that the patch has not been applied by the user.  The time
to deal with that issue is before it becomes impossible to
deal with it.

For example, for server machines, it might be resonable to
permit all users to open priviledged sockets, not just root,
so that the vast majority of your daemons can run without
priviledges by default.  At one point, SCO added a model
similar to the VMS "installed image" model, where the image
itself was attributed with priviledges, such as the ability
to open a reserved socket, the ability to open serial ports
owned by root, etc. (there were ~30 of them; can't remember
them all).

In any case, a non-executable stack goes quite a ways toward
preventing people from creating easy exploits using a return
to stack contents.  It forces people to use second order,
instead of first order, exploits.

This is an arms race, not a battle that can be definitively
won and never fought again.  I expect we will eventually get
to requirements tracking in interpreted languages, like Java
byte code and perl, etc..

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D1EDF9F.D10072FC>