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/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:04 EST