Messages in this thread | | | Date | Thu, 6 Jan 2000 01:12:10 +0300 (MSK) | From | Khimenko Victor <> | Subject | Re: why I run no-exec-stack patch |
| |
On Wed, 5 Jan 2000, Steve VanDevender wrote:
> Khimenko Victor writes: > > > So what if it's not a perfect solution. It will at least give us some more > > > creative exploits in the future. But it's certainly an improvement, and it > > > certainly raises the bar. So when my syslog says: > > > > > kernel: Possible buffer overflow exploit attempt: > > > kernel: Process crond (pid 612, uid 0, euid 0). > > > > > I can have a good laugh that even though a user beat me to the punch on an > > > exploit, I don't have to wonder if I've been rooted and don't know it. > > > > This is EXACTLY why it should NOT go in mainstream kernel. Since you just > > got message about unsuccessfull try. Was there successfull or not is not > > clear from that message. > > At least he got a message, which means that he can immediately > start investigating whether crond has a problem, rather than > discovering a mystery core file or for that matter a whole bunch > of trojaned binaries some time later. > The same message got I am since I'm used recompiled version of crond :-) Without any non-exec patch.
> It should not go in the mainstream kernel _because_ it prevented > a likely attack and made it clear that there was a vulnerable > binary? What are you smoking? > He prevented attack ONLY since attacker do not expected to find non-exec stack.
> > It's security via obscurity. It WORKS (unlike common belief). As long as > > it's not in mainstream kernel. > > Let's get this straight -- security through obscurity is putting > something somewhere where you don't think anyone will find it, > but leaving it unprotected. > It's what non-exec stack does for most daemons: he leave hole where it is but make just one common (used now by 99.9% of attackers) way to exploit it impossible. As far as attaker do not expect this papering it works. But when/if it'll be incorporated inmainstream kernel attackers willjust switch tools and this way will no longer common anymore (exploit developed to work around non-exec stack is harder to create and debug buy it works with normal stack as well).
> A non-executable stack is providing a real protection against > executing code in the stack segment.
Exactly.
> It's not hiding anything;
Formally speaking - no. Really - yes.
> on the other hand, the idea of placing the stack at a random > offset _is_ a security-through-obscurity measure, since it > doesn't protect against execution in the stack but merely tries > to hide exactly where it is. > Non-exec stack protect you from executing code on stack but IF attacker expect it it's not a good protection anymore (as Ts'o showed).
> And it works exactly the same way, and provides exactly the same > protection, no matter how many systems it's installed on or > whether it's in the mainstream kernel or not. It won't magically > start allowing execution of code on the stack when the number of > installations gets too large. > Attackers will change tools/cracks if it will be feasible. Clever attakers can work around non-exec patch already but it's crackers population minority by far. Most crackers are using cracks developed by others. As far as non-exec systems are exotic it buys your some security (more or less the same security as PowerPC/Sparc/etc buys your). When it's mainstream it'll no longer work.
> It's true that every effective, generally accepted security > improvement causes people who want to break security to > concentrate on methods that aren't prevented by that improvement. > Saying that this means that such security improvements shouldn't > be put into widespread use is logically untenable. As a > colleague succinctly said, "If you lock your door somebody may > break in through a window. That doesn't mean you shouldn't lock > your door." > It's wrong analogy. Non-exec stack is more like movind key from under carpet near door to your garden: key is STILL easily available (garden is usually available exen if house is still locked :-) but most attackers do not know about it. As far as most houseowners will do this attakers will try to find key in the gardenas well.
> So far everyone who has really tried to run a system with a > non-executable stack has testified that it has stopped a > significant number of security attacks without breaking any > software on their systems.
So does mere recompilatio with unusual optimisation flags.
> A bunch of people who haven't tried it have offered frequently bogus > arguments against it. > And published generic exploits to make crackers work easier :-) Then patch was changed and sample exploits was changed as well - last Ts'os one look great to me though...
> Of the arguments that have been offered against including a > non-executable stack _option_ in the kernel code, a couple are at > least somewhat reasonable: > > "Linus won't do it" -- Maybe so. On the other hand, I would hope > that Linus is willing to listen to reasonable arguments to > include a feature that has proven real-world benefits. > Linus heard all rguments many times. Repeating them will not help you for sure.
> "It's too hard/messy" -- On the i386, maybe -- but it has been > done and it works. It's not nearly so bad on some other > architectures. > Most users do not care about other architectures. It's all about benefits/price. This ration was not raised for last year (neither due changes in patch not due new pro- arguments ) so why Linusshould change his mind ?
> "It breaks $KILLER_APP" -- I have yet to see anyone offer the > example of $KILLER_APP that is truly in widespread use. And > again, no one is saying that a non-executable stack should be a > mandatory default; if it breaks your $KILLER_APP, then no one > will force you to use it. >
- 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/
| |