Re: Stack Smash Protection disabled (was HEADS-UP: Stack Smash Protection enabled by default for amd64 and i386)

[Elad Efrat <elad%NetBSD.org@localhost>]

On Fri, Nov 13, 2009 at 12:21 PM, David Holland
<dholland-current%netbsd.org@localhost> wrote:
> On Fri, Nov 13, 2009 at 12:57:53AM -0500, Elad Efrat wrote:
>  > > Well yes, and here's the thing. You are falling into the standard trap
>  > > of computer security cost/benefit analysis: you're assuming that the
>  > > risk of being attacked is infinite, and therefore the benefit of any
>  > > protection device outweighs its cost regardless of what the cost is.
>  >
>  > It seems we have all become economists and marketing experts.
>
> Anyone who asks for a cost-benefit analysis is an economist?

Asking for it is one thing, pretending to be able to put one together
is another. Anyway:

>  > I am not assuming the risk is infinite. I have pointed out that the
>  > impact of a stack overrun is the same in 1988 and in 2009, yet the
>  > speed of hardware on which software runs changed dramatically. This is
>  > a very important point. Next year we'll have faster computers that
>  > might drastically change the 5% figure; they will not change what
>  > happens if a stack overrun is exploited.
>
> Actually, next year we probably won't have especially faster
> computers, or had you not noticed that the clock-rate party is over?

Okay, so next year we won't have faster machines, and the following
year as well? Have we reached full capacity, captain?

>  > > There isn't exactly a long history of kernel-level stack-smashing
>  > > attacks. In fact, I can't offhand remember hearing about a single one
>  > > (other than in Windows) -- doubtless someone will refresh my memory,
>  > > but nonetheless it doesn't seem like a very high risk. And therefore,
>  > > it doesn't seem to me that there's much benefit, and in particular,
>  > > not enough to outweigh the cost.
>  >
>  > You begin by stating that there isn't a history of it, then you
>  > suggest that it is merely your own experience, and then you rule out
>  > the most popular OS in the market. [...]
>
> Yes, it is my experience; on the other hand, my experience watching
> these issues go by is likely longer than most people reading this
> thread.

What I had in mind when replying was noir's OpenBSD kernel exploits
from a few years back. Do you remember those, or have you forgotten
already?

The idea with many kernel vulnerabilities is that their exploitation
somewhat differs from many of the ones in userspace. I.e., it
sometimes (not always) takes a bit more work -- maybe even specialized
work for a particular bug -- to take advantage of. Obviously you know
that, and I presume you have vast experience in exploiting kernel
bugs, but for the sake of the followers of this thread who don't, I'll
add a note stating that today, unlike in the past, much less of the
holes found are actually disclosed.

> Meanwhile, the architectural flaws of Windows have little relationship
> to Unix kernels and using Windows supervisor-mode overflows (of which
> there have been quite a few, some notorious) as a risk model for a
> Unix-derived project is folly.

The only folly here is suggesting that just because you haven't heard
of something it doesn't exist.

That said, I'm quite certain at this point that our core team will
come around and settle this ridiculous issue for the benefit of the
NetBSD userbase. To paraphrase on a famous quote, I'd hate to see us
trade what can amount to a good night sleep for a few extra percentage
points.

-e.