[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 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
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
Main Index |
Thread Index |