lkml.org 
[lkml]   [2005]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: thoughts on kernel security issues
On Fri, Jan 14, 2005 at 11:15:19AM -0800, Linus Torvalds wrote:
>
> What vendor-sec does is to make it "socially acceptable" to be a parasite.
>
> I personally think that such behaviour simply should not be encouraged. If
> you have a security "researcher" that has some reason to delay his
> disclosure, you should see for for what he is: looking for cheap PR.

I disagree. First of all, we can't know what motivates someone, and
presuming that we know their motivation is something that should only
be done with the greatest of care. Secondly, someone who does want
cheap PR can do so without delaying their disclosure; they can issue a
breathless press release or "security advisory" about a DOS attack
just easily with a zero-day disclosure as they can with a two-week
delayed disclosure.

Sure, there are less-than-savory security firms that are only after PR
to drive business. But that's completely orthogonal to whether or not
the disclosure is delayed or not. Yes, "glorification" of relatively
trivial bugs is a problem; but whether or not the bugs are delayed
doesn't change whether someone issues an "iOFFENSE SECURITY ADVISORY"
which overstates the bug; it only changes whether they send the
advisory right away or a week or two later. (After all, the security
groups that subscribe to a zero-day "full disclosure" policy use
advisory/press releases glorifies their findings just as much.)

> (a) accepting that bugs happen, and that they aren't news, but making
> sure that the very openness of the process means that people know
> what's going on exactly because it is _open_, not because some news
> organization had to make a big stink about it just to make a vendor
> take notice.

A one or two week delay is hardly cause for "a news organization to
make a big stick so vendors will take notice". Besides, which is it?
Are it about security researchers that are after cheap PR, or "news
organizations forcing vendors to take notice"? Certainly I've never
that kind of dynamic with Linux vendors where reporters are trying to
get vendors to take notice; it doesn't matter whether take notice if
they are going to be releasing in two weeks later come hell or high
water.

> And yes, for this to work people need to get away from the notion of
> "let's apply vendor patch X to fix problem Y". What we should strive for
> (and what the whole system should be _geared_ for) is to have redundant
> enough security that people hopefully don't know of <n> outstanding bugs
> at the same time that allows for a combination attack.

Here, we certainly agree.

> And let's not kid ourselves: the security firms may have resources that
> they put into it, but the worst-case schenario is actual criminal intent.
> People who really have resources to study security problems, and who have
> _no_ advantage of using vendor-sec at all. And in that case, vendor-sec is
> _REALLY_ a huge mistake.

Nah. If you have criminal intent, generally there are far easier ways
to target a specific company. For example, many companies that have
multiple layers of firewalls, intrusion detection systems, etc., will
keep critical financial information in boxes left unlocked in the
hallways, and not bother to do any kind of background checks before
hiring temporary employees/contractors. Sad but true.

I'm quite certain that far more economic damage is being done by
script kiddies and by "insiders" using officially granted privileges
to access financial applications than by the hypothetical Dr. Evil
that hires computer experts to find vulnerabilities that could be used
to cary out criminal intent. And it's the script kiddies that we can
prevent by delaying disclosures by only a week or two, to give a
chance to get the fixes out to the people who need them.

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:2.249 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site