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>
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.
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.
So we can get back to bitching about Window's security flaws :D
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)
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...
Don't bother. There's no published exploit. Have a beer. Watch the game. Don't worry. Relax. What's your IP?
"...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".
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
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.
Sure. A program can ask the operating system kernel to Do Things. Now, someone has found out that when you ask the kernel to Do Things certain way, the kernel subsequently thinks you are the Boss.
Like, you have this stack of forms you want the computer signed. You hand them over to the computer. One of the papers is "Do whatever I say" form that would give you the Power. The computer won't read it and just signs it along with the others, then hands you the forms back.
How's that for an explanation?
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.
TO DO:
... ad infinitum
Log onto slashdot.
Bash Microsoft.
Bash the bashers of Microsoft.
Bash the bashers of the bashers of Microsoft.
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.
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)'
Prevent email address forgery. Publish SPF records for y
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...)
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."
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 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.