Local Root Exploit in Linux 2.4 and 2.6 795
Anonymous Coattails writes "Summary from the advisory: 'Locally exploitable flaws have been found in the Linux binary format loaders' uselib() functions that allow local users to gain root privileges.'"
Copyright Poo Poo (Score:5, Interesting)
Credits:
========
Paul Starzetz has identified the vulnerability and
performed further research. COPYING, DISTRIBUTION, AND MODIFICATION OF
INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH EXPRESS PERMISSION OF
ONE OF THE AUTHORS.
Did I violate you buy hitting ctrl-c and ctrl-v? Yeah copyrights stink even in free and open source realm. Oh yeah I guess Polly boy has something to put on his resume now as if someone else was going to steal his glory and get away with it.
Once again... (Score:3, Interesting)
They've got a pretty good record. Unfortunately, kernel-level stuff is nasty -- how do you fix embedded devices?
Re:Failed on RHEL (Score:3, Interesting)
Re:*sits back* (Score:4, Interesting)
I can only laugh out loud. Read this story [lwn.net] for example.
Re:Failed on RHEL (Score:5, Interesting)
This could help (Score:2, Interesting)
Local Access is always a trump card (Score:4, Interesting)
Local vs. Remote (Score:3, Interesting)
Re:What, no remote exploit?!? (Score:5, Interesting)
It seems that, even though they were written in different times and without security as the first concern, a sufficiently large number of bug fixes will eventually result in code that is almost as secure.
isec.pl's guys rule (Score:5, Interesting)
Isec.pl has done a lot for the open source world, they've found lots of vulnerabilities (which is good - vulnerabilities ARE like any other bug):
Take a look at the impressive curriculum of those guys:
d_path() truncating excessive long path name vulnerability
Linux kernel do_brk() lacks argument bound checking [www.isec.pl]
Linux kernel do_mremap() local privilege escalation vulnerability [www.isec.pl]
Linux kernel do_mremap VMA limit local privilege escalation vulnerability [www.isec.pl]
Linux kernel setsockopt MCAST_MSFILTER integer overflow [www.isec.pl]
Linux kernel file offset pointer races [www.isec.pl]
Linux ELF loader vulnerabilities [www.isec.pl]
Linux kernel IGMP vulnerabilities [www.isec.pl]
Linux kernel scm_send local DoS [www.isec.pl]
Linux kernel uselib() privilege elevation [www.isec.pl]
Guess what, they're also the guys who discovered the mozilla hole diclosed today: Heap overflow in Mozilla Browser NNTP code [www.isec.pl]
Those guys are impressive. In particular, Paul Starzetz is the author in most of those kernel holes, along with a guy called Wojciech. They always contact the kernel maintainers before discosing the vulnerability, etc. Basically, they're having the same effect than a security audit. Except that they're doing it for free, so they deserve respect, I think. And yes, Linux is having too many kernel-level vulnerabilities. More than XP if I'm counting them right. Perhaps someone should offer a job to those guys so they can audit parts of the kernel better.
(And I can understand that copyright policy - there're people who probably look at those announcements, ctrl+c and ctrl+v and they release their own announcement twisting dates claiming that they're the guys who found it first)
Re:Local Access is always a trump card (Score:3, Interesting)
Linux is soo insecure... *sigh* (Score:2, Interesting)
These are exploits in the most basic portions, against which a sysadmin can do nothing other than keep on patching things. It's not like you could have tunned this system to make it very secure, no, no matter how carefully you (or your distributor) set it, bang, a local exploit seems to be found every month or two.
I'm seriously considering going back to BSD (maybe Debian GNU/NetBSD [debian.org]?), which seems to have a much much much better security track.
Major Difference (Score:3, Interesting)
First and foremost, the terms to which you must agree before you download and install. The MS downloads and patches often come with "interesting" end-user license agreements. Meanwhile, with the Linux kernel download, you can do whatever you like, including (*gasp*) fix it yourself, if you have the ability.
Secondly, when you use Microsoft update, you don't know what is getting installed. With many things, like XP service pack 2, you get a lot of cruft that is useless.
As far as popularity being the #1 indicator for available exploits: if that were true, Apache would be the most-exploited web server, since it has 65%+ of the market. Unfortunately, that's not true. IIS has many more published exploits, in spite of the fact that the code for Apache is available for inspection by the black-hats.
There *is* a such thing as "being more secure." Yes, we can't be perfect. (In fact, I don't believe there is a such thing as perfection.) But that doesn't mean that one OS can't be objectively better than another.
Is this real? (Score:4, Interesting)
For all we know, this is a social engineering trick to spread some malicious code. Let's wait until some official folks eg. CERT, or your vendor/distribution responds. Are the people who released this code have some credibility that can be verified independently?
Re:Unfortunately not the only one... (Score:3, Interesting)
Between December 15th and today, Linus has committed many changes to
the kernel. Between January 2nd and today, Andrew Morton has committed
several changes to the kernel. 3 weeks is a sufficient amount of time
to be able to expect even a reply about a given vulnerability. A patch
for the vulnerability was attached to the mails, and in the PaX team's
mails, a working exploit as well. Private notification of
vulnerabilities is a privilege, and when that privilege is abused by not
responding promptly, it deserves to be revoked.
Yawn.. oh well. I'm sure someone will point out how this is MUCH faster than the turn around that M$ will give. But hey.. this is Slashdot after all.
Re:What, no remote exploit?!? (Score:3, Interesting)
The same flawed engine is used to display your folders (turn on the location bar and type in a url, see what happens), your desktop, and your email in Outlook express and even most 3rd party apps. If you use AOL, it uses IE to render web pages. When you view a help file, guess what it's IE. It is impossible to avoid IE on a windows system.
By choosing a browser which uses it's own renderer and an email application that does the same, you ARE at least reducing the opportunity for 3rd party sources to access the renderer and it helps a great deal. The problem your left with then is that apps like firefox are still dependent on IE's trust model (the entire trust model of the OS is built around it) when running on windows. This is why almost every major "exploit in firefox" only affects firefox on windows.
There are plenty of other broken pieces in windows, but I've tried to stick to examples of why simply not using IE still leaves you vulnerable on windows.
On windows your best bet is to run as an unpriv'd user as much as the OS allows, use 3rd party email and browser apps (that use a different renderer). And don't forget to stick it behind a firewall that isn't running windows or better just keep it off the network. Also never put a disk in a windows box that came from outside your network unless it is from a known publisher and you've scanned it for viruses on a disconnected machine. Aside from that, you really just have to pray.
None of that is saying any particular other OS is secure, that's another matter entirely. I'm just saying that clearly windows is NOT and you CANNOT remove the components needed to lock it down.
Re:*sits back* (Score:3, Interesting)
The concept of local security is usually ignored in the MS side, that someone already using the machine could access/modify things that he should not.
Most Microsoft related advisories/reports are centered in remote vulnerabilities, things that only have a meaning for a network connected machine accessing services or being accessed from outside.
Of course, a local vulnerability could be exploited if some piece of software (i.e. a web app) have an entry point, and what should be running with the low apache priviledges or in a chroot jail becomes a systemwide security problem.
Re:*sits back* (Score:2, Interesting)
But, well, no MS exploit is strictly a "remote root exploit" unless it's a local process running with admin privs.
So... take this exploit along with any known exploit (say, libXpm or libtiff) on a user's web browser and you have a remote root exploit.
Doesn't work? (Score:3, Interesting)
No, think about it ... (Score:4, Interesting)
Actually copyrighting the exploit is kinda cool. Say you are a admin, and some kid gets fresh and tries this out. "Hey kid, not only am I nailing you to the wall for this, but I am turning you over to the guy who "owns" it and you get to pay him a nice fine." No, I think that is it pretty hilarious that the code is copyrighted.
Sera
Re:Distribution restrictions (Score:5, Interesting)
It's irrelevant anyhow. If you didn't sign a contract to keep it secret, they have no grounds to gag you. They can copyright their exact words and can (and probably should*) control the distribution of those words, but copyright does not give them any protection of the facts contained within. And neither does anything else.
For the same reason, when you are accidentally mailed something with one of those "you must delete this immediately if you are not the intended recipient", unless it is actually and literally classified, you have no obligations. It's just to scare people.
The legal system has a ways to go before you can be obligated by an email out of the blue, or a random announcement on a webpage taking rights not granted to them by copyright but implementing no real access control (i.e., attempting to obligate you after you downloaded a page; it might work if you make it a condidion of reading but not just out of the blue, after the fact).
*: Reputation is important. One of the reasons copyright should not be straight-out abolished is its usefulness in making sure that words are correctly attributed and can be quality controlled, a virtue you are so used to you may never even think about until it is gone.