[lkml]   [2005]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: thoughts on kernel security issues
    On Wed, Jan 12, 2005 at 10:25:06PM -0500, Dave Jones scribbled:
    > > Whatever. I happen to believe in openness, and vendor-sec does not. It's
    > > that simple.
    > That openness comes at a price. I don't need to bore you with
    > analogies, as you know as well as I do how wide and far Linux
    > is deployed these days, but doing this openly is just irresponsible.
    > Someone malicious on getting the announcement of a new release
    > gets told exactly where the hole is and how to exploit it.
    > All they'll need to do is find a target running a vendor kernel before
    > updates get deployed. Whilst this is true to a certain degree
    > today, as not everyone deploys security updates in a timely manner
    > (some not at all), things can only get worse.
    That might be, but note one thing: not everybody runs vendor kernels (for various
    reasons). Now see what happens when the super-secret vulnerability (with
    vendor fixes) is described in an advisory. A person managing a park of machines
    (let's say 100) with custom, non-vendor, kernels suddenly finds out that they
    have a buggy kernel and 100 machines to upgrade while the exploit and the
    description of the vuln are out in the wild. They have to port their
    custom stuff to the new kernel, compile it, test it (at least a bit), deploy
    on 100 machines and pray it doesn't break. During all that time (and the
    whole process won't take a day or even two) the evil guys are far ahead of
    the poor bastard managing the 100 machines (since all they need is one
    exploit which will work on any of our admin's machines). One other factor
    that makes it hard for such a person to apply the patches is simply that there
    is no single place to find the security patches in. He goes to,
    for instance, and what does he find? A nice description of the vulnerability, a
    discussion, a list of affected kernel versions and credits which usually
    list vendor advisories and kernel versions and very rarely a link to an
    archived mail message or a webpage with the patch. Hoping he'll find the
    fixes in the vendor kernels, he goes to download source packages from SuSe,
    RedHat or Trustix, Debian, Ubuntu, whatever and discovers that it is as easy
    to find the patch there as it is to fish it out of the vanilla kernel patch
    for the new version. Frustrating, isn't it? Not to mention that he might
    need to backport the fix, if he runs an earlier version of the kernel.
    And now assume that everything is as extremely open as Linus says - the
    admin has the same access to the exact information the vendors on vendor-sec
    have, together with the same fix they have (in form of a simple patch
    available without fishing for it all over the place). He starts the race
    with the bad guys exactly at the same time they start running looking for
    the vulnerable machines on the 'Net. Priceless, IMHO.
    I guess that, contrary to what you've just said above, hiding the
    information is irresponsible.
    Having said that, I don't think everything should be as extremely open as
    Linus would want it to see, but rather the way he proposed (and which many
    folks agreed to) with the 5-day (or so) embargo for the advisory release and
    with the patch(es)/discussion openly available to anyone interested (based
    on the premise that most people learn about vulnerabilities not from
    security lists but from security bulletins, tech news sites, user forums etc.)

    best regards,

    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2005-03-22 14:09    [W:0.024 / U:20.812 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site