Messages in this thread | | | Date | Tue, 1 Aug 2000 12:07:55 -0700 (PDT) | From | <> | Subject | Re: 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/
| |