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.

Not a new vulnerability

[Anonymous Coward]

This is the same vulderability that was disclosed a few weeks ago. The advisory was updated on March 1st to include exploit code.

Re:Which kernels are effected

[Broken_Windows]

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

Re:Damn (all your base are belong to us)

[kompiluj]

Oh really? I am running 2.4.25 on my all systems for two weeks already - since the first advisory. Patch or be patched.

Not a big deal really

[jmoen]

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-

From the link...

[Spoing]

1. Synopsis: Linux kernel do_mremap VMA limit local privilege escalation vulnerability

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.

Old news

[phaze3000]

This is why 2.6.3 was released, as discussed in this [slashdot.org] 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.

known since 18. feb. 2004

[gst]

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...

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Here we go again

[bafu]

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 medium old news.

[Anonymous Coward]

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 /.

if you patched two weeks ago, you can ignore this

[redmoss]

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.

Patched in 2.6.3 apparently

[petabyte]

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.

Re:Many eyes, but wide open or tight shut ?

[hobbesmaster]

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.

Re:"Windows users: want Security, install linux"??

[fwarren]

The goal a lot of people have is to make Linux mainstream, that means that less and less knowledgeable users will be using it. If Linux continues to suffer from kernel exploits from time to time just like Windows then those same users will be running executable mail viruses built for Linux just like they do for Windows now.

On a Windows box, there would have been no peer review. So instead of being discovered after 5 years, the only way we would know about it is if some hacker had reversed engineered it and exploited the problem. Then Microsoft would set on a patch for 6 months...if they decided to fix it at all.

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.

Re:Many eyes, but wide open or tight shut ?

[BiggerIsBetter]

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.

Re:More critical vulnerability in FreeBSD

[cperciva]

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.

Re:Many eyes, but wide open or tight shut ?

[bickerdyke]

gentoo's emerge -U world comes pretty close to an automatic update

this vulnerability announcement is a month old

[Anonymous Coward]

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.

http://www.slackware.com/changelog/stable.php?cp u= i386
"
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- 2004-0077
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.

Re:Many eyes, but wide open or tight shut ?

[spitzak]

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!

Re:Many eyes, but wide open or tight shut ?

[the_2nd_coming]

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.

Re:Which kernels are effected

[Anonymous Coward]

*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.

Re:Which kernels are effected

[Rosco P. Coltrane]

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?

which are vulnerable

[CAIMLAS]

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.

Re:2.6.3?

[Anonymous Coward]

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.

Re:Many eyes, but wide open or tight shut ?

[iantri]

Automatic Update? Put the following into your crontab at an interval of your choosing:

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

[account_deleted]

Comment removed based on user account deletion

Re:Story is a troll!!!!!

[LuSiDe]

And >= 2.2.26 fixed this also.

Re:if you patched two weeks ago, you can ignore th

[stock]

"Its a source-level patch. See `man patch`. I understand the sarcasm inherent in your statement and yet I don't see peoples' problem with doing a quick recompile and reboot. Its really that simple. "

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

Re:Many eyes, but wide open or tight shut ?

[Carl T]

RedHat at least had a desktop icon that alerted users if updates were available

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.

Re:This is medium old news.

[Anonymous Coward]

And please note, that March 1 is the date of an update of the announcement. The bug was fixed in 2.4.25 and the original announcements are from mid february.
Everybody considering this bug "news" should check his way to track security announcements!

Re:Story is a troll!!!!!

[Ironica]

Dont you think a security hole that is VERY OLD and still there is a lot worse than one that just slipped in with the last revision?

But, what he's saying is, it's NOT still there. It's been fixed already.

Re:Proof-of-Concept Code

[Monster Zero]

If you try to compile with GCC 2.96, you get the following error:

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:

$ ./mremap_pte /bin/ping /bin/bash

[+] kernel 2.4.20-28.7bigmem vulnerable: YES exploitable YES

MMAP #65530 0x50bfa000 - 0x50bfb000 [+] Success

Usage: ping [-LRUbdfnqrvVaA] [-c count] [-i interval] [-w deadline]

[-p pattern] [-s packetsize] [-t ttl] [-I interface or address]

[-M mtu discovery hint] [-S sndbuf]

[ -T timestamp option ] [ -Q tos ] [hop1 ...] destination

New exploit for an already fixed issue.

[Anonymous Coward]

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.