[lkml]   [2000]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Stopping buffer-overflow security exploits using page protection
    On Sun, 30 Jul 2000, Derek Martin wrote:
    > I've never really been able to understand the logic behind this
    > argument:
    > We have holes A B and C in our dam. Hole A is very large, and it's low on
    > the dam so currently lots of water is flowing through it. Holes B and C
    > are maybe a little smaller and are much higher up in the dam, so it's
    > harder for water to get through them, and currently very little water is
    > flowing throught them, as the leakage from hole A is keeping the water
    > level below hole B and C. But even though there's an easy way to fill hole
    > A, we shouldn't bother because it's much harder to fill B and C (for
    > whatever reason -- maybe there's a school of piranha living near B and C),
    > and once we do fix A the water will start leaking through B and C, though
    > probably not as quickly.
    > That just seems ridiculous. Wouldn't you fix hole A ASAP? Certainly by
    > plugging A, you have not achieved perfection, but you're a bit closer, no?
    > And you have gained yourself some time to figure out how to plug holes B
    > and C before exploits for them become widespread. To me, this seems like
    > a Good Thing(tm).
    > Said another way, what significant drawback is there to including such a
    > patch into the kernel proper? Are there any? If not, would seem that
    > REDUCING the potential vulnerabilities would be well worth the effort,
    > despite the fact that they have not been eliminated.

    This should really be a FAQ.

    The problem is that you don't reduce any potential vulnerabilities at
    all. For every buffer overflow exploit out there you can modify it and
    produce a version which will work against a non-exec stack page on an
    x86. It is not hard. I was actually considering producing a "Smashing
    the Stack for Fun and Profit, Part II: Non-Exec Stacks" text to show just
    how easy it really is. For now, I suggest you check out the VULN-DEV
    archives -- a few very helpful people on that list walked me through how
    to produce non-exec stack exploits.

    If a non-exec stack ever got accepted into the kernel, then exploit
    writers would simply start coding for non-exec stacks. The end result is
    that you would gain precisely nothing. And what you would lose is that
    you would have broken the x86 API -- for nothing. So, yes, there is a
    drawback, and no you don't reduce any vulnerabilities. Linus has already
    rejected such patches for this reason. Check out the Libsafe
    documentation for a little bit of background and references.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:57    [W:0.024 / U:11.900 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site