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 Thu, Nov 12, 2009 at 6:58 PM, David Holland
<dholland-current%netbsd.org@localhost> 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.)

If you have SSP in place, the weight of each is changed such that the
"panic" is more likely and the kernel compromise is "less" likely.
What it means is that your chances of being alerted are higher as
things will most likely stop working rather than continue to work
under the supervision of someone else. (FWIW, based on my short, but
mandatory experience in a military environment, I can tell you that
the above is priceless. Performance can be bought, security can't.)

Now, what Steve said is very important here: as time goes by, the 5%
figure will most likely change for the better, i.e., the impact will
be much, much lower; if we really cared, we could take this a step
further and argue that this 5% performance hit is merely observed but
never experienced, but let's not over complicate things as it appears
people like their numbers.

The above suggests that there's no rationale for having SSP disabled
by default or disabled at all for that matter.

-e.