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.
looked at in great depth just recently, after a critical vulnerability was found. A few weeks go by and another hugely important hole is found...
Now I know the consequences of a problem bear little relation to its root cause, but I am a little surprised at how this managed to find its way through all these eyes looking at the offending code a week or so ago. Actually making it work as a security hole looks to be reasonably complex, (which may be why it wasn't found, I guess), but if one piece of code can have 2 major vulnerabilities in as many weeks, maybe it's time to start worrying about when Linux *does* take over the desktop...
I thought the automated 'Stanford Checker' (sp ?) was ideal for this sort of problem ? (Where the returned value from a function is ignored...) Perhaps it was flagged up but took some in-depth analysis for the kernel developers to realise it really was a problem...
So, is this a master-stroke of the development model, with various people around the world all individually checking code and Hey! Someone found something, or is it a "failure" where all those people missed it the first time around, and it's a pure fluke it was found now.... I'm still not sure, but I'll give the benefit of the doubt to the model - hey, it's been fixed!
Simon
Physicists get Hadrons!
Wasn't there a (third) problem with mremap back around summertime too? These all sound like barebones, common mistakes. Who is contributing this source? Was it all the same person? Maybe we should be checking his/her code a bit more closely!
Sig.i>
Get windows CD
Boot
Install
bah
Computers are like air conditioners.
- They stop working when you open Windows.
I really did not want to spend my Sunday patching kernels.
huu dupe? that thing was released over a week ago!
This is the same vulderability that was disclosed a few weeks ago. The advisory was updated on March 1st to include exploit code.
After all, if they can expect people to license Linux from them, they should be providing support.
...I'm going to have to patch the kernels on the Debian servers and reboot again?
That'll be the third time in as many months.
My operat~1 system unders~1 long filena~1 , does yours?
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
In Linux it's a bug...
In Windows it's a feature.
Just compare the time and effort putting together the 3 page write up on the bug to the cost of reviewing and fixing the code in question when it was originally written. I believe the study that found that once the bug leaves the development shop to go to consumers it costs $9000 per line to fix. It's as true in open source as it is for closed source.
Oops. That HTML posting problem. This was what I was trying to say:
Apparently, only <= 2.6.2 is affected. How could this be fixed in 2.6.3 without anyone noticing that it might be a problem in earlier kernels?
Roses are #FF0000, violets are #0000FF, all my base are belong to you
So we can get back to bitching about Window's security flaws :D
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-
Slowly but surely as Linux is getting more mainstream it seems the same kind of holes that perpetually plague Windows exist in Linux as well.
It might be time to take a page from the MS book and take a few weeks for a full line by line audit.
Kernel 2.6.4-rc2-bk3: Never, I'll Never turn to the Dark side, I'm open source...like my father before me.
Bill: So be it, open source
Bill: if you will not be turned, you will be destroyed (shooting purple lightning bolts)
Bill: You will pay the price for your lack of vision
Kernel 2.6.4-rc2-bk3: Linus please (in agony).
.....to be continued
I await my -5 (Troll)
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...
Could someone please say what this vulnerability is in English? That article made my head hurt.
Jay | http://oldos.org
When a Windows vulnerability is patched, it is proof that closed source software is evil.
Wne a Linux vulnerability is patched, it is proof that open source software is wonderful.
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".
Another kernel vulnerability was recently found in all FreeBSD (4.X and 5.x) versions.
:
e s/ FreeBSD-SA-04:04.tcp.asc
The TCP/IP stack can be stopped by sending unordered TCP fragments.
This is a serious remote vulnerability, and any FreeBSD with an open TCP port should be patched ASAP.
Here's a link to the official advisory
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisori
Regardless of the operating system you are running, always keep everything up to date.
{{.sig}}
"...And how do you avid windows-baiters react to it? How come you hypocrites just blow Windows bugs out of proportion while attempting to cover up Linux kernel holes?..."
Um, the source code for the *fix* is listed *in* the article (you didn't read it did you?)
i don't call posting fixed code and owning up to an exploitable coding error "covering up".
Neither have I, but that wasn't the point of my post.
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.
A lot of people I've seen using Linux have a false sense of security and therefore aren't as careful as they are on Windows (which is a scary thing because we all know how insecure Windows is).
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 guy investigating mremap is saving a new vulnerability for every week. He's working only to get his name printed everywhere. I cannot take this seriously. If he's a genuine security analyst, he'd fix _all_ mremap related bugs within 1 patch.
My biggest grief, is him not releasing source code patches for genuine kernel.org kernels. If he's so good to release sploits, he's good enough to submit source code patches.
Robert
OK time for me to tilt at a few windmills. Aside from the date being off by a year (the link quotes the date as 05-01-2004), is this supposed to be 1st of May or the 5th of January?
In an international forum and for clarity, ISO 8601 dates. Therefore: 2004-01-05.
Sorry for the rant, but I work for an international company, and have spent sizable parts of meetings trying to figure out which version of a document is "most recent", 2/3/04 or 3/2/04.
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.
Get a windows CD
Boot
Reboot
Install
Reboot
Install some more
Reboot
Continue installation
Reboot
Register windows installation
Change a setting
Reboot
bah
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.
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 +
What winds up happening is I pay MS to produce a product that I have very little input on. I buy the off the shelf solution to then develop 50% of the solution anyway. And, then it crashes, the documents are incorrect (updates might be available on their web sites), and I have no way of figuring out what the issues are without paying more $s for something I paid for already. If I tried to pull the same trick, I would loose my client.
Linux side is someone spots the issue, makes us aware of it in most cases. People have something more important than a paycheck at stake get to work on a fix for the problem. A, or multiple, potential fix(es) is(are) put up. Sometimes a fix goes straight in with minimal review (it works, most liked it), sometimes the fix gets kicked around to hash out any potential problems (in the full light of day, normally my apps do not break when the fix is rolled out.)
I like the public knowledge aspect of OSS. Yep, hackers have access to it also, but closed source never seemed to stop them, it just stop me from protecting myself.
Maybe we need to look at the next step for OSS? Maybe there is a better model for building OSS? Maybe companies might start providing more donations (like cheap lic fees) to a foundation that rewards freelance OSS programmers with cash for tackling certain problems (and does not pay until the code is peer reviewed and bug checked to a reasonable extent.) Maybe that would work better... Are certain organizations not starting to do that?
Given how much OSS has accomplished in the past decade with its relative lack of fees and "structure", imagine what might happen if more companies started using their proprietary source software budget to put bounties out on features they needed in OSS. True, not all features would they want to make public, but enough they would wat to so as to dramatically cut everyone's costs (GNU lic is important because of this). Most companies actually have very close to the same needs. But, their money goes to legal and marketing fees more than it seems to go to actual development fees with off the sheld software. What an economic waste! Check out John Nash for a rather different rather OSS view of the world.
In the end, you are left with a decision. The programmers at MS are very bright. The programmers in OSS are very bright. The real difference is the perceived safety of being able to blame MS (who you can not hold responsible yet - name one successful law suit against MS for the failure of their software to function as advertised) versus the cost effectiveness of not paying for huge legal and marketing fees (as well as other corporate overhead having very little to do with getting better or more code). I am not against programmers getting paid. I am against sloth and leeches in a corporate setting destroying the market in which programmers get paid.
InnerWeb
Freud might say that Intelligent Design is religion's ID.
I can't exploit this on my SUSE kernel. All I get (after many attempts) is:
[+] kernel 2.4.21-192-athlon vulnerable: YES exploitable YES
MMAP #65530 0x50bfa000 - 0x50bfb000 [-] Failed
Perhaps this hasn't gone completely unnoticed...
You may trust your authorized users, but do you trust their passwords, habits in storing passwords ("You don't expect me to remember that, do you? Where are my post-it notes..."), and wisdom to not extend trust to ANYONE?
Do you also trust users to not run a piece of malicious code that shows up purporting to be some groovy new Linux app that will do some groovy new thing? Afterall, it would only have to require a vanilla user account... and Linux never gets viruses, so why worry? ;)
I think you see where I'm going with this. Local exploits need to be patched too, and sysadmins all too frequently think they don't because they are "only local".
perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10)'
Let me get this straight, it has nothing to do with the bug from a year ago, except that it affects the same code in the same system call? Call me unenlightened, but, that sounds pretty similar to me.
I hate sigs.
ISO dates are the way to go - for the sanity of everybody concerned. They sort lexically in a sensible way, they're in a reasonable order, and they're unambiguous (YYYY- not YY-).
/rest/ of the world would change over.
This, of course, is why nobody uses them.
*sigh*
As the evil dictator-like sysadmin, at work all my in-house intranet tools report ISO dates. I had a few people confused at first, but now it's the accepted format at work for things like archive directories (hundreds of directories named NN-NN-NN, NN.NN.NN or NNNNNN can get rather confusing - YYYY-MM-DD is so much easier).
Now, if only the
While we're at it, can we have the ISO paper sizes adopted by the few holdouts, too? (I only wish...)
RTFA!
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.
No, these kernels are affected. My guess is that kernels 2.2.26, 2.4.25. and 2.6.3 will be effected. The effect of a vulnerability is usually a bugfix release, as an unpatched kernel negatively affects security.
Umm.
"On a Windows box, there would have been no peer review."
I doubt that even Microsoft lets security fixes be released without having other Microsoft programmers review all the relevant code. A more accurate comment might be:
"On a Windows box, there would have been no public peer review."
Wouldn't grsecurity provide protection for this?
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.
I ran the test code in the advisory on a stock 2.4.25 build and it printed out NO and NO for both questions [vulnerable and exploitable].
Is this really a bug? [tinfoilhatmode] Is the advisory code correct? Or is this just so old that both 2.4 and 2.6 lines have it fixed already?
Tom
Someday, I'll have a real sig.
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
Just what the subject says.
A typical user experience.
1) Buy computer with Windows XP Home Edition pre-installed.
2) They get a virus, perhaps even a trojan. Or maybe a worm, since the computer wasn't up-to-date. Or they were stupid and opened MyDoom. Regardless, it cripples the computer.
3) They buy or download an antivirus software. Perhaps their computer works well enough to install it, and reinstall Windows if it does not.
4)Ok, finally a working computer again. But since they browse the internet as administrator (as it works by default) they get spyware. Lot's of spyware. It builds up on each other and Internet Explorer has trouble starting. Pop-ups occur on every website, even Google or when IE isn't open. Perhaps their credit card info is stolen.
5) If their lucky, they would have heard of Ad-Aware or Spybot Search and Destroy and they somehow get it on their computer to install it (no IE remember?). It deals with most of the pop-ups. But nothing really works right. Reinstall Windows.
6) Go to step 2.
I work at the campus helpdesk, so I see students with these sorts of problems all the time. I have a problem respecting an OS that will get a worm before the user has a chance to do Windows Update, an occurance I've seen a few times.
There is a patched kernel at least for RedHat:
https://rhn.redhat.com/errata/RHSA-2004-065.html
Note in the third paragraph:
"Paul Starzetz discovered a flaw in return value checking in mremap() in the Linux kernel versions 2.4.24 and previous that may allow a local attacker to gain root privileges. No exploit is currently available; however this issue is exploitable. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0077 to this issue."
This is the same CVE as the article. The patch was issued 2004-02-18.
This issue was patched in Fedora on 19 Feb with 2.4.22-1.2174. See the Fedora announce list here:
http://www.redhat.com/archives/fedora-announce-li
God is imaginary
Comment removed based on user account deletion
Just to add my .02, I've tested this exploit code on a representative sample my boxes here, some running stock fedora kernels, some running 2.6 kernels, and NONE of the systems is exploitable, though the reports vary depending on kernel.
/home/jjs ./a.out
/home/jjs ./a.out
So, before the fud machine starts churning out all these opinions on how insecure linux is, let's check our facts OK?
neo:
(tty/dev/pts/1): bash: 1016 >
[+] kernel 2.6.3-ck1 vulnerable: NO exploitable NO
gibson:
(tty/dev/pts/1): bash: 126 >
[+] kernel 2.4.22-1.2174.nptlsmp vulnerable: YES exploitable YES
MMAP #65525 0x50bf5000 - 0x50bf6000
[-] Failed
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
Well, I think this proves that the "security through obscurity" model is, at best, ineffective. If it has been so long there for anyone to see and the "good" guys didn't see it, what makes you believe that the "bad" guys would spot it?
I don't have hard data to prove this, but I believe that the following two points are true: (1) there are more good guys than bad guys, or otherwise society as we know it wouldn't exist; and (2) good guys are smarter than bad guys, because our current social organization tends to favor being honest. Good guys get good salaries, bad guys are sent to jail.
So, if it took many smart good guys five years to find this vulnerability, how many years it would take a few stupid bad guys to find it?
I tried the "Proof-of-Concept" code. Nice thing about it is that it tells you two things. 1) If your kernel is vulnerable 2) If your vulnerability is exploitable.
I have one kernel that is vulnerable but not exploitable according to the Proof-of-Concept code. Saves me some time to not patch, recompile and reboot a new kernel.
I wish future vulnerability announcements will be like this one. e.g. contain Proof-of-Concept exploit code that can tell me whether or not the kernel/software I am running is vulnerable and/or exploitable.
This patch requires a reboot, right?
Are you being deliberately naive - to load a fixed kernel, it is required to load the fixed kernel, you do understand that, correct? However, for anything other than loading a new kernel, linux does not need to be rebooted, and that includes system lib updates, distribution upgrades etc.
The advisory was released Feb. 18, so this has all been public knowledge for over two weeks. This USENET post shows the vulnerability and upcoming exploit was known about, and slashdot is just plain late on this one.
You have had two weeks to patch your systems. I know slackware's advisory was sent right after the vulnerability became public knowledge.
this is why anywhere unpriviledged users can write (/home, /var, /tmp, etc.) should be on a partition mounted 'noexec'. If a cracker can get local access, but not execute their own code, they are limited as to what they can do. This is also another good use of chroot, although the BSD 'jail' is a more robust solution.
That's a very naive, idealistic argument. American business often maximizes shareholder value by being as dishonest as possible, short of clearly breaking commonly enforced laws. Under your argument, Darl McBride is a "good guy" because he's a) rich from the SCOX pump-n-dump and b) not in jail (yet).
Anyway, go read "The Art Of War" or watch "The Godfather". It is a serious error to assume your enemy is weak, and I would recommend against that philosophy when securing critical assets.
Don't forget
So
Please. So, to run it I have to chmod +x it; ooh, but /home is mounted noexec, so I log as root, cp it to ... hmm ... /usr/local/bin ... nope, no /usr/local ... ok, /usr/bin it is ..., oops, it's mounted read-only, I'll have to mount -o rw,remount /usr then I'll chmod +x it, aaah ... now I go back to my regular account and execute it.
How this compares to send me a fscking html-with-vbscript that will be executed while in the preview pane of Outlook Express and downloads another executable that has the power to install itself as a device driver and run in kernel mode?????
Even if I have to click on the attachment, it will execute right away!!!!
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
I believe that these exploits couldn't be in the kernel *if* it was written in Ada95.
r.