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.
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?
> 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.
A non-executable stack is providing a real protection against
executing code in the stack segment. It's not hiding anything;
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.
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.
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."
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. A bunch of people who haven't tried
it have offered frequently bogus arguments against it.
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.
"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.
"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