Slashdot Mirror
New Linux Kernel Vulnerability
Stop Or I'll Noop writes "Paul Starzetz writes, "A critical security vulnerability has been found in the Linux kernel memory management code inside the mremap(2) system call due to missing function return
value check. This bug is completely unrelated to the mremap bug disclosed on 05-01-2003 except concerning the same internal kernel function code." Full scoop here."
Update: 03/07 20:53 GMT by T : This vulnerability (and fixes) were mentioned briefly in an update to this earlier posting.
This is the same vulderability that was disclosed a few weeks ago. The advisory was updated on March 1st to include exploit code.
From the release: Version: 2.2 up to and including 2.2.25, 2.4 up to to and including 2.4.24, 2.6 up to to and including 2.6.2
Oh really? I am running 2.4.25 on my all systems for two weeks already - since the first advisory. Patch or be patched.
You can defy gravity... for a short time
Seems like none of the current releases are affected by this anyway. Ref. the article:
Only version: 2.2 up to and including 2.2.25, 2.4 up to to and including 2.4.24, 2.6 up to to and including 2.6.2
-jmoen-
Local, not remote.
In general: If an attacker has local access or can gain the equivelent by using a remote access tool, a local exploit can be a problem.
So, personally I'm not too worried though others with different types of users or configurations might have a high level of concern.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
This is why 2.6.3 was released, as discussed in this slashdot story from the 18th of Feb. The date on the linked article is March 1 - this is a second document on the same vulnerability that gives more details. It was not released at the time to give people a chance to patch.
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
actually this vulnerability was announced on 18. feb. 2004 by isec (see http://lwn.net/Articles/71682/).
isec just waited some weeks until they released the exploit...
This story is old.
Version: 2.2 up to and including 2.2.25, 2.4 up to to and including 2.4.24, 2.6 up to to and including 2.6.2
2.6.3 and 2.4.25 have been out a while. This is _not_ a new vuln. All this will accomplish is a bunch of idiots saying "see, linux is insecure".
Do I laugh or do I cry? ...
Laugh, I would say. While both laughing and crying are versatile enough to be used regardless of whether it is a time of great happiness or great sadness, laughing is definitely more "out there".
just when I had finished compiling 2.4.25 on my systems..
Anyone who "just finished compiling" the latest release of their favorite kernel tree is all set (assuming the installed it), since this "new kernel vulnerability" is only new in the /. sense. I would think that people who are super-concerned about such things would recognize that in reading the bulletin.
Did I read the security bullentin correctly
No, you did not. :-( When it said...
2.2 up to and including 2.2.25, 2.4 up to to and including 2.4.24, 2.6 up to to and including 2.6.2
...you mistook the 2.2 for a 2.4 and thought that it effected your 2.4.25 kernel.
This is the second mremap() vulnerability finaly making it to slashdot. Note the date on the linked page, March 1.
/.
You just thought it was the third because you already heard about two, and forgot that sometimes things take a week or so to make it to
This is partially redundant to a few of the other posts here saying that this vulnerability was already disclosed several weeks ago. However, I thought I'd add that if you already patched, check the vulnerability ID; in this case it's CAN-2004-0077. Your patch should have specifically mentioned this ID. If not, you need to patch again.
Thank $DEITY I don't need to patch/reboot again. I was starting to get a bit annoyed at having to patch the kernel twice in two months. Scheduling reboots of machines in use by many people is no fun.
I'm fairly sure this was patched in 2.6.3. Running the test code included in the advisory on my 2.6.3 (vanilla) system shows:
[+] kernel 2.6.3 vulnerable: NO exploitable NO
There's also a patch to mremap listed in the 2.6.3 ChangeLog. So I don't know how "new" this bug is.
Erm, the problem is that this is a local exploit, not a remote one. I doubt that very many crackers have been using this exploit, because you have to have a local account in the first place to do it.
In Linux, peer review found it, fixed it and made the information available, so you know that you have an exploit.
Linux seems much more Mainstream to me. Until people write perfect, bug free, secure software, give me a system that at least I can keep up to date and have a chance to protect myself.
vi +
My thinking is that Linux on the desktop is going to need a contingency plan for a widespread vulerability, similar to what Microsoft does with Automatic Updates.
I'm guessing you don't use Linux then. All major distros release such updates very quickly, and RedHat at least had a desktop icon that alerted users if updates were available. The kernel will get patched if it needs to, but it's up to the distro vendors to include something "idiot proof" to yell if the system needs an update.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
Yes, more critical... in the sense that an easily detected (just look at the packets), non-spoofable (you can't do this without having finished a TCP handshake first), denial of service attack is more serious than a root exploit.
Tarsnap: Online backups for the truly paranoid
gentoo's emerge -U world comes pretty close to an automatic update
bickerdyke
this hole was found and patched by vendors a month ago. i personally submitted to slashdot at least 10 stories detailing this hole and how to patch it, and i was quite obviously ignored.
p u= i386- 2004-0077
http://www.slackware.com/changelog/stable.php?c
"
Wed Feb 18 03:44:42 PST 2004
patches/kernels/: Recompiled to fix another bounds-checking error in
the kernel mremap() code. (this is not the same issue that was fixed
on Jan 6) This bug could be used by a local attacker to gain root
privileges. Sites should upgrade to a new kernel. After installing
the new kernel, be sure to run 'lilo'.
For more details, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN
Thanks to Paul Starzetz for finding and researching this issue.
(* Security fix *)
"
2.4.25 and 2.6.3 are NOT affected by this hole, and there is a patch for 2.4.24 which you can make yourself by diffing a vanilla 2.4.24 kernel with slackware 9.1's 2.4.24 kernel source package.
CmdrTaco, before you post another "announcement" like this, do your homework. last thing we need is more security disinformation surrounding linux.
If your eyes were a little wider open you would see that this is NOT A NEW BUG! In fact it is the exact same one (the *second* in mremap(), not the third) as reported in a Slashdot article well over a month ago.
I actually read the bug report then, and I read it now, and when I got down to the bug explanation (with the lines of X's representing memory) I realized it was the exact same one I had seen before!
uhh...no, see the diffrence is that Linux might have many local exploits that have not been found, but the structure of the OS makes it very hard for a remote exploit.
I am the Alpha and the Omega-3
*sigh* So many posts about which version is affected. Any kernels > 2.4.24 and > 2.6.2 will NOT be affected. This has been fixed for half a month at least and went into 2.4.25 and 2.6.3. If in doubt read the changelog, or heavan forbid the source.
Wonderful. scsi is broken on 2.6.3-gentoo-r1. My burner and USB disks don't work, and that's worse than a local root.
- ide-scsi is deprecated for CD burners
- USB now relies on hotplug/libusb/whatnot
Jesus man, why don't you read the fucking 2.6 migration FAQ before posting bollocks?
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Ok, so I read the write up.
Here's the immediately pertinent part:
Proper exploitation of this vulnerability leads to local privilege escalation giving an attacker full super-user privileges. The vulnerability may also lead to a denial-of-service attack on the available system memory.
Tested and known to be vulnerable kernel versions are all
So it looks like we've all got to update to the latest of respective trees. I guess the days of running a kernel for months on end are pretty much over.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Because this story is really old, and the vulnerability was fixed when it was announced, and 2.6.3 was released.
Slashdot: when news breaks, you get the pieces.
On Debian/Red Hat with APT:
apt-get update && apt-get dist-upgrade
On Red Hat with up2date:
up2date -u
On Mandrake:
urpmi.update && urpmi --auto-select
And so on.. Now obviously these could be imrpoved (i.e. mail the admin if it fails), but auto-updating is a lot easier under Linux.
Comment removed based on user account deletion
Oh yes i know how to use /usr/bin/patch . But where is the patch itself? like linux-2.4.24-mremap.patch ? for instance
cat linux-2.4.24-mremap.patch | patch -p0
would do the job. However _where_ is the linux-2.4.24-mremap.patch to be found?
Robert
SuSE has a similar thing. Dunno about other distros.
There are a couple of problem here though:
There are a number of steps that need to be taken before a patch is installed, and each of them may take quite a bit of time: computer needs to check for patches, mirror server (if any) needs to have patches from main patch server (in my case this is sometimes an issue, but I could go directly to ftp.suse.com, if it's not completely bogged down already), user needs to be alerted, user needs to choose to patch. All this could be done in an automated way, but it would still take some time, during which the machine would be vulnerable.
And then, after patching, programs or the whole machine may need to be restarted. This can't very well be automated, at least not by default.
I'm semi-admining a SuSE 8.2 box where the automatic update script emailed me every day with a list of already-installed patches. Stupid. :-P So I got it to not email me. So now I have no clue when I need to reboot, and the machine is probably open to several known vulnerabilities right now.
I'd say that single(ish)-user machines really need to be properly firewalled, but unfortunately there's no such thing as a satisfactory default policy. (Outgoing IRC traffic, for instance, should be open for IRCers but not for anyone else.) On multi-user machines there's no substitute for vigilant admins.
This signature is not in the public domain.
Error: unbalanced parenthesis in operand 1.
The solution (for me) was to compile it with GCC 3.3.2.
The output on my system (unfortunately for me) is:
It should be noted that this is simply a new way of exploiting the same mremap bug that had been reported before. It was fixed with the 2.4.25 kernel patch.