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>
I really did not want to spend my Sunday patching kernels.
huu dupe? that thing was released over a week ago!
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.
"...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".
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 why 2.6.3 was released, as discussed in this slashdot story from the 18th of Feb.
Slashdot in general needs to get a grip. Far too much of this kind of thing going on. Its getting close to the edge of not worth spending any time at all on slashdot.
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)'
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."
You know there are -- among the many, many, many open vulnerabilities out there -- two which are particularly problematic for Windows users. (There are many more out there, but I figure I'll focus in on these two for now.
The first one allows an attacker to mask the real address of the site you're viewing in IE. So, go and open up a spam claiming that Paypal needs you to update your credit card number, and you'll actually see PayPal.com as the URL. The second one allows an attacker to crash IE and exploit arbitrary code when a user views a picture on a web page under IE.
As a Computer Programmer, I understand how hard it is to create 100% bug free code. Any system as complex as Windows or Linux is bound to contain some bugs and / or vulnerabilities. However, when an exploit is found in Windows (to the best of my knowledge those two exploits have yet to be patched), it takes forever to get a fix to the public.
On the other hand, as soon as I heard of the vulnerability in the Linux Kernel, I have the following options:
Now, whereas I am pretty certain Slackware will have a package available for me to update my kernel in another 48 - 72 hours, and if it's absolutely urgent for me to fix it I can either disable it or fix it myself (something Windoze won't let you do -- although the nature of the vulnerability in the kernel may make disabling it impractical. But still, at least you have the option), Microsoft has not, to the best of my knowledge, fixed these vulnerabilities, even though it's been months.
This is why Open Source Software is so great. Technically sophisticated users hold the destiny of the software in their own hands. And I haven't even begun to get started on how great it is not to submit annoying feature requests, but to make software do what you want it to do.
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?
HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
But every time i hear about security holes and people saying the latest version fixes it, i wonder how many "old" version are running around the world, and how long it will take (if ever) to be updated.
This is so stupid. They are not the same kind of holes. People who write things like this don't understand the severity of exploits. This is LOCAL, not remote. If fact, I am hard pressed to think of any remotely exploitable problems in the linux kernel in the last 3 years. A local root isn't a problem for 98% of linux systems. As long as any daemons listening for network connections are up to date, you really don't have anything to worry about. One could run 2.4.0 with no patches without worry as long as all network daemons are up to date.
In fact, I know of a red hat 6.2 box just running apache and ipchains on a 100mhz box that has been running for at least 4 years without a single security problem. It probably has at least 20 local roots, but it doesn't matter because apache has had a good security history.
The point is, we almost NEVER see the equivalent of local roots on windows boxen. Everything we see is remotely exploitable. It's rare that Linux sees anything remotly exploitable (in popular software...Joe's cgi script doesn't count). And when we do, the "fragmentation" of distributions that everyone bitches about helps immensly. Because most packages are compiled differently, the memory address to exploit are different. So it's difficult to exploit a box and usually you have to brute force it. As we see more things like non-executable stack patches and random memory patches these problems will be extremely difficult to exploit.
The proof is in the pudding... when's the last time we saw anything in linux so widely exploitable that 90% of affected machines are infected within 10 minutes of the release of a worm? We should have seen hundreds of apache worms by now since there are at least as many apache installations as IIS. MySQL? MySQL has gained huge popularity and is on almost as many boxen as SQL server. Why haven't we seen a single MySQL worm?
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?
Who said that I was talking about this vulnerability . All I said was that it is impossible to do any proper testing of a patch if it is realeased minutes/hours/days after it is discovered.
Two things:
1. Why aren't "days" enough to do proper testing? I agree that minutes aren't enough. And neither are hours usually, but there cases where I would argue that, depending on the kind of change, the testsuites and the QA requirements.
2. In OSS, most times a patch isn't released in the conventional meaning of the word ("released", I mean). The patch is made available (often when it is checked into CVS). What will be released is a new tar ball or announcement, after the QA process. Me, I consider it released, when my favored distribution has an updated package for it on its security site. And contrary to some Microsoft fixes, I never had a Mandrake or Debian security update break my installation - so the QA process seems to work.
It's simple to mix up those, because in closed source you don't see the step where a patch/fix is internally distributed from devs to QA. In OSS you do, but that doesn't imply an official release.
But on the other side, the difference in availibility matters. Having access to the patch before a security update is officially released, gives me a choice. If it's criticial enough for my infrastructure, I can dig into it and do my own QA and deploy it even before an official announcement is available.
Heck, if it's important enough, I can start even before a patch is available, because I have the source. And if you follow security lists, you will notice that it is no exception that a so created patch will find its way into the official release (in other words: the time to release is cut short, because a suggested fix is already available the moment the core team starts looking at the problem).
Keep an eye on which arguments are silently dropped in replies. Not always, but often times it's very telling.
Still doesn't answer the question "is this NEW?" I mean why is this being posted on slashdot? Obviously the kernel teams know about the flaw and have already fixed it.
Oh oh, I found a bug in Win 3.11... oh wait... that's an old release? Dang... Nobody will want to hear about that...
Tom
Someday, I'll have a real sig.
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.
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.
Don't forget
So
Yes, it is saving you.
That doesn't mean someone won't release an exploit that doesn't trigger pax though. It's just the way this particular example of the exploit is coded that PAX (part of Grsec) is catching. Doesn't mean someone can't code up a version of the exploit that won't trip PAX and hack you to bits!
Upgrade to the latest grsec, there are patches for the latest 2.4.25 kernel.
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