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

[David Holland <dholland-current%netbsd.org@localhost>]

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?

 > 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?

Anyhow, what you're saying here is just repeating the same fallacy.

 > > 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. Since you brought up Google, you might want to amuse yourself
by digging up the first security alert I ever posted.

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.

 > > It's been noted elsewhere that theoretically the overhead of SSP is
 > > not supposed to be 5%; it's supposed to be negligible. Where is this
 > > 5% overhead coming from?
 > 
 > That does not matter.

Yes, it most certainly does.

 > [ad hominem remarks snipped]

-- 
David A. Holland
dholland%netbsd.org@localhost