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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:06 EST