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? Have a nice day! Denis Hoffmann
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.
Have a nice day! Denis Hoffmann
Thanks,
Roman.
--
- -
| Roman Drahtmüller
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.
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...)?
This means that the argumentation is not fully conclusive in terms of the
impact that such a DoS bug has. It resembles that story with the man going
to the physician, telling him "doc, if I touch this, it hurts!". The doc
answers "so don't touch this then!".
Greetings,
Roman.
--
- -
| Roman Drahtmüller
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
Also worms, dont just spread but also install backdoors. A remote root backdoor would be a nifty thing for a worm programmer :) But this Bug is a DOS, right? So all it could do is bring your machine down? peace, Tom -- this is a maillist account, so please send personal replies to cso[at]trium[dot]de
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
Patrick Schneider wrote:
Why should I use then chroot, if an exploit can circumvent it??
If someone has an account on your box (your webserver also does!) he can mostly ever DoS your box. (Sure you can protect your box from DoS with ulimit etc...)A chroot (jail) is just to prevent simple attacks on binarys etc. like if your apache has a hole, someone can use this hole to exploit local programms etc. thats the reason why you use a chroot -> remove unneeded binarys from the webserver access. Google also about breaking out a chroot. In the most cases a chroot can be broken in a few minutes... HTH
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
participants (6)
-
Denis Hoffmann
-
Gustavo Muslera
-
Patrick Schneider
-
Roman Drahtmueller
-
Sven 'Darkman' Michels
-
Thomas Seliger