El mar, 26-11-2002 a las 06:23, Roman Drahtmueller escribió:

...

Hi there!

I just came across this article: http://www.securiteam.com/exploits/6E00F2060U.html Summary: A vulnerability in the Linux kernel allows local attackers to cause it to halt. The flaw seems to be related to the kernel's handling of the nested task (NT) flag inside an lcall7. What says SuSE about this topic? Do you advise a kernel update? Which SuSE-versions are affected? We're busy with the updates right now as I write. Kernel updates are non-trivial, so they take some time.

What that particular bug is concerned: Give me a shell, and I'll have your machine die in two minutes via resource starvation or bad tricks to some other direction. A bug that freezes your machine may be ugly, and a DoS is security-critical, yes. But there is no better security tool than userdel if you have users on your system that mess with the stability of it. If that bug could be triggered remotely, you could bet that we'd be loud about it.

I'm not exactly a kernel programming, but if the vulerability exist and is easy to exploit and most systems are unpatched (after all, you need access to exploit it) then the next worm like Migthy, that install a source, compile it and run with user wwwrun, named, nobody, in a chroot jail or whatever could exploit it and be really harmful. And upgrading a kernel is something that must be handled with more care than upgrading servers or libs... so is better to fix the kernel when is not urged by a remote exploit.

El mar, 26-11-2002 a las 12:55, Roman Drahtmueller escribió:

...

...

What that particular bug is concerned: Give me a shell, and I'll have your machine die in two minutes via resource starvation or bad tricks to some other direction. A bug that freezes your machine may be ugly, and a DoS is security-critical, yes. But there is no better security tool than userdel if you have users on your system that mess with the stability of it. If that bug could be triggered remotely, you could bet that we'd be loud about it. I'm not exactly a kernel programming, but if the vulerability exist and is easy to exploit and most systems are unpatched (after all, you need access to exploit it) then the next worm like Migthy, that install a source, compile it and run with user wwwrun, named, nobody, in a chroot jail or whatever could exploit it and be really harmful. And upgrading a kernel is something that must be handled with more care than upgrading servers or libs... so is better to fix the kernel when is not urged by a remote exploit. Not really... The worm can't propagate any more if the machine has halted. If that worm takes advantage of a root exploit in the kernel, it is somewhat different. But, on the other hand, why would an attacker (a worm) want to attack root on a system where it is possible to propagate already (the worm broke into the system already...)?

Remember a lot of dos/windows virus. First spread, then attack. Think in Roron worm, to name one recent, it sends itself, and certain days it destroys everything. The damage that could do to Linux credibility a worm that exploit that kernel vulerability and at 3pm GMT (to say something, could be at 0 minutes of any hour) halt all infected servers, well, could be high. Even worse, what if the vulnerability that permits that this worm spread not only work in x86 linux systems, that could give you a lot of infected systems, and of all of them, only Linux systems will be down. Of course, here I suppose that in a (near) future will be a remote vulnerability in some kind of server running under linux, and this kind of exploit comes before the fix of that vulnerability (the worms for the ssl bug appeared months after the vulnerability was fixed), but is bad luck tu assume that the bad guys are dumb or slow, or that local vulnerabilities are only exploitable by locally know real people users Saludos Gustavo

Hi list,

...

install a source, compile it and run with user wwwrun, named,

...

nobody, in a chroot jail or whatever could exploit it and be really harmful.

Just a dumb question from here: Why should I use then chroot, if an exploit can circumvent it?? Or am I wrong? What about (free)BSD jails? Bye, Patrick

Hmm maybe a little off topic, but how secure is a chroot if you do it right? I always hear "bah its easy to break", but if you drop root privs in the chroot (plus taking care of /dev's and stuff), isn't it relatively secure? Its not absolutely secure, but it will stop many "standard out of the box skript kiddie" attack... It wont stop a dedicated hacker, but most things wont do that. Patrick Schneider wrote:

Just a dumb question from here:

Why should I use then chroot, if an exploit can circumvent it??

Or am I wrong?

What about (free)BSD jails?

Bye, Patrick

-- this is a maillist account, so please send personal replies to cso[at]trium[dot]de