Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

On Thu, Nov 12, 2009 at 10:05:07PM -0500, Steven Bellovin wrote:
> On Nov 12, 2009, at 8:45 PM, Elad Efrat wrote:
> > On Thu, Nov 12, 2009 at 6:58 PM, David Holland
> > <> wrote:
> >> On Thu, Nov 12, 2009 at 03:30:23PM -0500, Elad Efrat wrote:
> >>>> After protests from multiple developer because of the performance hit
> >>>> I've reverted the changes. SSP is now off by default (except for
> >>>> library and network daemon builds) on all platforms, in particular
> >>>> for NetBSD/amd64 and NetBSD/i386 kernels.
> >>> 
> >>> Unfortunately for rmind@, pooka@, and haad@, until proven otherwise,
> >>> it seems more developers are interested in having SSP enabled by
> >>> default. Please put it back. No developers are more equal than others.
> >> 
> >> I don't see that there's a convincing rationale for turning it on in
> >> the kernel.
> > 
> > Unfortunately for you that does not change the situation one bit.
> > 
> > However, for pure fun, let's look at the "rationale" here. If your
> > kernel is built without SSP and a vulnerability that it might have
> > protected against is being exploited, there's a fairly good chance
> > that it will result in either stack corruption leading sooner or later
> > to a panic, or to a kernel compromise. (Not root compromise -- there's
> > a very big difference.)
> Before we had plists in the kernel, I wasn't as worried.  We have them now.

And now the proplib FUD.  That kind of blanket statement from such a
respected security professional is just sad.  You're worried you have
plists?  You've had ioctls almost forever!  And yes, I'm just throwing
that like that.  Go and stop me.

Like other people, I am concerned by the 5% penalty.  And to me it seems
that all the people favoring setting USE_SSP to yes for the kernel only
have to offer that the user can re-compile his kernel.

Well, guess what?  It works either way.  Of all the NetBSD machines I
have, some of them will have a use for those 5%, and I'll grant you that
some will be just fine hypothetically crashing instead of hypothetically
falling into the evil plans of an hypothetical overlord because of an
equally hypothetical bug.

In the end it is a question of balancing the defaults, but, before
anyone even suggests it, provinding two kernels is completely out of

I am ambivalent on the question of the default of USE_SSP.  But it's
not because of the removed insecurity it provides, or the marvelous
(and recent) fastestness of the NetBSD kernel.

It's more a debate that goes like, on one hand, we have people who
really care about security.  Will they really use a kernel they didn't
compile, even provided by TNF?  Will they really use the kernel TNF
provides (hello, modules!)?  Yeah, right.

But then, let's be honest, the situations were the 5% performance gain
actually makes a difference are few and far between, and people in such
situations might want to use different compilation options for their
kernel anyway.

I can think of one situation where the 5% performance gain does make a
difference, though.  When some lame ass blogger does a poorly operated
benchmark of, say, NetBSD 6.0, 5.0 and whatever will be the greatest
Linux and FreeBSD at the times, it will go like this:  "pfff, those
idiots at NetBSD, 5.0 kicks 6.0's ass for performance".  And here goes
Slashdot and the crowd of cretins.

So in the end, I think it's only a matter of hype.  Don't get me wrong,
but somehow a feature whose only purpose is to mitigate bugs that
haven't been found is not a very positive message.  An honest one,
maybe,  but plain honest truth is not necessarily what sells the

I apologise for the car analogy, but a fast red polluting Ferrari will
always bring more readers to the cover of Quatroruotte than a green

Quentin Garnier - -
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.

Attachment: pgpCl8Yl5ADVU.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index