lkml.org 
[lkml]   [2000]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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