Local Root Exploit in Linux 2.4 and 2.6
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.'"
← Back to Stories (view on slashdot.org)
*awaits justifications and explanations of why this is nothing like Microsoft*
Read down to the Credits on the link and you see this line:
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.
How do people find this stuff? Amazing. Open source is astounding.
When do I get my kernel update?
It's a good thing I've got the patch downloa
I tried it on a couple of boxes. It tries to exploit a race condition, so it won't necessarily work all the time. However I have tried it a few dozen times and haven't gotten it to work yet. (One RH 7.3 box and one RH 9.0 box)
ayershome.org/users/eric
since windows is more "single user" oriented, most local exploit flaws on windows do not get very much publicity.
For instance, shatter attacks are still a very large threat for multi-user windows systems
I need no exploit to gain root privileges, I just login...
ayershome.org/users/eric
Is there ever a time when you can consider your systems secure against an attacker with physical access?
I should mention that enabling ELF format is still highly recommended (after the patch for this is released of course) and unless you do special programming work in linux then enabling a.out format is not recommended.
"uselib" is a Linux-specific extension, and, as a result, has received much less real-world testing than traditional UNIX system calls. Keep in mind that the traditional UNIX system calls have received millions of man-years of real-world testing in large user communities likely to attempt both remote and local exploits. It is not surprising that Linux-specific extensions are at a much greater risk of containing serious security problems.
COPYING, DISTRIBUTION, AND MODIFICATION OF
INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH EXPRESS PERMISSION OF
ONE OF THE AUTHORS.
Is it just me, or is this mind-bogglingly stupid? A security advisory which can't be redistributed freely? Imagine if the same approach was taken to important warnings in the real world -- "There's a tsunami heading towards you... but you're not allowed to redistribute this warning to all the people around you without my permission."
Security advisories should be in the public domain.
Tarsnap: Online backups for the truly paranoid
Right, let's compare the flaw in a single kernel versus the ENTIRE OPERATING SYSTEM of Windows, GUI, shell, and associated apps like Internet Explorer as well as user-ran executable attachments in Outlook, which have nothing to do with Microsoft.
What happened to all the "Linux is just the kernel" stuff? Oh, that's right, we were bashing Microsoft.
Besides, if you mean "past year" as 2005, then this means Linux is first out of the gate.
Incidentially, the finding of exploits found in bind and sendmail has really slowed to a crawl.
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.
In this context, that's what "local" means: That you have a local account, even if you are accessing it with telnet or ssh.
A "remote" exploit is one that can be used by someone who has a network connection to the machine, but no account on it.
Don't you think it's more convenient for you to be able to hack multiple machines over LAN? Another reason to choose Windows over Linux.
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
Linux kernel do_mremap() local privilege escalation vulnerability
Linux kernel do_mremap VMA limit local privilege escalation vulnerability
Linux kernel setsockopt MCAST_MSFILTER integer overflow
Linux kernel file offset pointer races
Linux ELF loader vulnerabilities
Linux kernel IGMP vulnerabilities
Linux kernel scm_send local DoS
Linux kernel uselib() privilege elevation
Guess what, they're also the guys who discovered the mozilla hole diclosed today: Heap overflow in Mozilla Browser NNTP code
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)
2^5
And when some third-party developers write buggy code, they really write buggy code. Remember "Return to the Pool of Radience: Ruins of Myth Drannor". Now that was a buggy game!
Zagreus sits inside your head, Zagreus lives among the dead, Zagreus sees you in your bed and eats you in your sleep.
It's the sysadmins of University email and webservers across the country going apeshit as suddenly the entire student body potentially has root...
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
raw diffs to for those brave souls who want them
Time flies like an arrow, fruit flies like a banana.
Thank God I run Firefox!
This means only that it must be used in conjunction with a process that is exploitable. Let's say, for example, apache was running and there was an exploit available to it. Well, most people would say "oh well.... can't trash the whole machine, the apache user doesn't have the rights." Well once apache is compromised, they can likely find a way to inject the local exploit code for the apache user to run. Once that's accomplished, apache user becomes root user. From there, the machine is 0wned to borrow a word.
Yes it's serious but I expect a fix shortly...
May I recommend that Do not run this code if you can not understand what it is doing.
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?
ato
Shatter attack
It's a problem with Win32 messaging if windows aren't secured properly. It's possible for a process to send windows messages (the ones inherited from Windows 1.0) to another process, regardless of what account the processes are running as. There are a few messages (WM_TIMER esp.) that, as a parameter, take an address for the owning thread to jump to. You can also fill the contents of a text box with a message.
Process A is a privilieged service running as SYSTEM. Process B is a malicious program running as a restricted user.
A creates a window on the interactive desktop (a big no-no) with a textbox in it.
B fills the textbox with exploit code with a message and then sends a WM_TIMER or similar to A with the exploit's address. A is now executing the exploit code.
First, there are ways to divide the window handle space into seperate parts, each securable with desktop and window station objects. Both of these are kernel object types with ACLs: you can't send a message to a window unless you have access to the conaining desktop.
Also, the JOB_OBJECT_UILIMIT_HANDLES flag for Job objects will prevent messages from leaving the job.
MS guidelines specifically forbid the use of windows from a priveleged process from appearing on the interactive desktop, since NT 3.51, for this reason. This doesn't stop many third-party app developers from creating insecure apps (virus scanners esp.) that do just that.
Winlogon's windows (press ctrl+alt+delete) are safe because they are on a seperate desktop that normal users can't send messages to.
I'd really like to know what's being done about this pitiful trend of Linux security, where it's 10x as easy to find a vulnerability in the kernel than it is in any app on the system, where isec releases at least one critical vulnerability for each kernel version.
And given his description of how he found these problems, plus his frustration about getting Linus and akpm to reply, his tone is even somewhat understandable.
All that this needs is to be combined with a vulnerability that grants remote access to a machine and you have a serious problem (provided that the remote access allows them to exploit this).
- and if we had some ham, we could make ham and eggs, if we had some eggs... seriously, we could play "what if" games all day long, but let's not blow this issue all out of proportion. It is what it is and nothing more, and at the end of the day it will have resulted in none of the sort of disasters we see on a regular basis with the microsoft platform...
I keep seeing posts here about somebody setting their grandma up to run $DISTRO but nobody will admit then that said grandma might be easily duped into clicking that link in that e-mail to get the latest cookie recipe (or some other nonsense) and woops! there goes a local exploit and now her box is Pwn3d!
This sort of thing is not as easy as you suppose - in the windows world one can write a quick vbscript to cause all sorts of nonsense, but on a unixlike platform such as Linux there would be a considerably higher barrier to the success of such shenanigans.
It sounds like you're saying this isn't such a big disaster because there aren't that many Linux users...and that strikes me as a ridiculous point of view.
I see you've failed to understand my statement. I'm at a loss as to how my meaning could have been contorted from "a potential local exploit isn't going to cause the sorts of internet disasters as we see regularly with windows" into the bizzare statement "hardly anybody uses linux" - (strokes beard thoughtfully). We can put the lie to that sort of thinking by simply considering the apache webserver, it's market share, and security record, compared to the microsoft iis web server, it's market share and it's security record. And by "security record", I don't mean "counting the number of advisories from all linux vendors and comparing them to the number of advisories from microsoft", which is a meaningless comparison. No, I mean "compare the frequency, scope and severity of the security incidents associated with the two platforms", which would be much more telling.
In short, this one is too big (too exploitable, too public) to wait until Monday.
My life would be so much easier if profs didn't have such a hard on for Linux and let us admins install OpenBSD. Good thing I get paid overtime. Oh wait, I don't.
Serve Gonk.
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
Slashdot, where armchair scientists get shouted down and armchair theologians get modded up.
All those MCSE dorks down the hall are gonna give me sh*t for the next week.
Reminds me of a punchline to my favorite Scottish joke:
"Aye, lad...ya screw ONE goat..."
I might know what I'm talkin' about, but then again, this is Slashdot...