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, 14 Jan 2005, Theodore Ts'o wrote:
    >
    > But please reflect that the glory-hounds would in fact get
    > more attention if they were to announce their findings right away,
    > along with the exploit that does something public and visible, such as
    > taking down kernel.org ---- and that sometimes the security
    > researchers who insist on delayed disclosure are doing so out of the
    > best of intentions, and will only work with organizations that repsect
    > their requests. You may not agree with them, but name calling is not
    > going to help matters.

    I disagree violently.

    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. You
    shouldn't make excuses for it. Any research organization that sees PR as a
    primary objective is just misguided.

    Also, there's a more fundamental issue: the "glorification" of bugs. Bugs
    aren't news. We have various small bugs all the time, and many of them are
    at least potential local DoS issues. Suppression of information is what
    _makes_ these bugs news.

    So I dislike the _culture_ that vendor-sec encourages. THAT is the real
    problem. And hey, it may be better than some other places. Goodie. But
    dammit, it needs somebody to be critical about it too.

    What's the alternative? I'd like to foster a culture of

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

    Right now, people seem to think that big news media warnings on
    cnet.com about SP2 fixing 15 vulnerabilities or similar is the proper
    way to get people to upgrade. That just -cannot- be right.

    (b) reporting a bug openly is _good_, and not frowned upon (right now
    people clearly try to steer even white-hat people who have no real
    incentive to use vendor-sec into that mentality - because it's the
    "proper channel")

    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.

    I'm convinced most security firms are like the virus firms: they react.
    They react to things they see on the cracker lists etc. They use a lot of
    the same tools to find problems that really bad people find. That means
    that the problems they "discover" are often discovered by the bad guys
    first. Sure, they have their own people too, but that's like saying that
    _we_ have our own people too.

    And that makes the whole "nondisclosure to avoid bad people" argument
    pretty much totally bogus, something that nobody who argues for vendor-sec
    seems to be willing to accept.

    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.

    Linus
    -
    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: 2009-11-18 23:46    [W:0.022 / U:1.124 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site