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

[Steven Bellovin <smb%cs.columbia.edu@localhost>]

On Nov 12, 2009, at 10:49 PM, Quentin Garnier wrote:

> 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
>>> <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.)
>> 
>> 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.


"Stop you"?  I've never tried to stop anyone from disagreeing with me.  I make 
no claims to omniscience or infallibility; I'm always happy to learn.  And I 
would hope we could disagree politely on a technical issue.

However, you're not the only one to ask me for more of an explanation of that 
point.  Ioctls and other, older system calls -- up to and including open() -- 
that take string arguments generally use them relatively simply, with little or 
no parsing required.  

Plists are different.  (And no, I'm not saying they should be removed from the 
system.  At this point, my real complaint about plists is that they're often 
composed of bad XML, by which I mean XML that doesn't really use the expressive 
power properly, thereby complicating some applications.)  By their nature, they 
require many string operations to build or to parse.  They're nested 
structures.  The components are inherently very variable in length.  The 
relative complexity of the string operations for plists is much higher than 
what we had before; therefore -- in my opinion -- the risks of bugs is much 
higher.

Also note that I didn't say I wasn't worried before.  I said -- see above -- 
that I wasn't *as* worried.

Your other point is about hype.  You do have a point, though I'm not convinced 
that 5% is a big enough difference to matter that much.  However, security 
problems can also generate negative publicity.  (I think that Firefox may be in 
trouble soon on those grounds -- have you noticed the relative security hole 
rate of it vs. IE lately?  IE is still hurting from architectural security 
issues, but overall they've had many fewer serious bugs of late, and people are 
starting to notice.)

All that said, here it's a question of balance.  I am, as you note, a security 
guy; I thus tend to attach a greater weight to security issues than to 
performance.  That's my own opinion -- and it's just that, an opinion.  I'd 
like to try to agree on the facts, however.

                --Steve Bellovin, http://www.cs.columbia.edu/~smb