Slashdot Mirror
Kernel Exploit Cause Of Debian Compromise
mbanck writes "The cause of the recent Debian Project server compromise has been published by the Debian security team: 'Forensics revealed a burneye encrypted exploit. Robert van der Meulen managed to decrypt the binary which revealed a kernel exploit. Study of the exploit by the RedHat and SuSE kernel and security teams quickly revealed that the exploit used an integer overflow in the brk system call. Using this bug it is possible for a userland program to trick the kernel into giving access to the full kernel address space'. This issue has been fixed in 2.4.23. Thus, the Linux kernel compromise was not Debian specific."
It's fun to see how security research shifted from applications to kernels lately.
{{.sig}}
If the kernel was coded in visual basic, this wouldn't be happening.
What kind of person spends that much time trying to find exploits in operating system kernels? Likewise, why do I spend so much time on www.thinkgeek.com/fortune.shtml? We are a sad people.
Esoteric reference.
The evidence mounts: users should be eliminated.
Roving Web-Teleoperated Robot
And thus, a previously unknown kernel exploit is discovered and patched! (Now how many more exist?)
Hats off to the Debian Security Team.
I believe an earlier article said that it appeared that he sniffed a password to the box.
Recently multiple servers of the Debian project were compromised using a Debian developers account and an unknown root exploit. Forensics revealed a burneye encrypted exploit. Robert van der Meulen managed to decrypt the binary which revealed a kernel exploit. Study of the exploit by the RedHat and SuSE kernel and security teams quickly revealed that the exploit used an integer overflow in the brk system call. Using this bug it is possible for a userland program to trick the kernel into giving access to the full kernel address space. This problem was found in September by Andrew Morton, but unfortunately that was too late for the 2.4.22 kernel release.
This bug has been fixed in kernel version 2.4.23 for the 2.4 tree and 2.6.0-test6 kernel tree. For Debian it has been fixed in version 2.4.18-12 of the kernel source packages, version 2.4.18-14 of the i386 kernel images and version 2.4.18-11 of the alpha kernel images.
to the winodows hole found the other day. Has anybody heard if that was fixed yet(not sure if it has been 48 hours yet). Technically this hole was fixed before it was found. It looks like another win for open source.
Stay tuned for new sig...
yup... this'll make ms-windows look good on the uptime front for at least a week...
Just wondering if they will still support us lowly 7.3 and 8.0 users anymore with a fix for this.
Just like Nancy Reagan said: Users are Losers.
That's "Mr. Soulless Automaton" to you, Bub.
So it sounds like someone used a compromised user account to get in, ran a binary that exploited the bug, and got root that way. This is a local exploit, then.
Linux is a compelling choice in the Free Software world because of its pace of development and wide availability of software. However, it is this strength that is becoming a weakness. Perhaps it is time to slow down and review with more vigor to mimic the accomplishment of OpenBSD.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
You appear to be trying to write a kernel. Do you want to:
http://linux.bkbits.net:8080/linux-2.4/diffs/mm/m
The patch is from 9 weeks ago... I wonder if the exploit writer got the idea from looking at the kernel changelog...
I had just convinced myself there was no compelling reason to upgrade my kernel from 2.4.22.
Actually, there still isn't, since the likelihood of my machine "coming under attack" is slight. But, what's the point of running Linux if you're not going to get all worked up over things like this ;-)
Happy make menuconfig to all!
quiquid id est, timeo puellas et oscula dantes.
Comment removed based on user account deletion
I agree with you totally. It's one thing to say that Linux is rock-solid secure, but in the real world this just might not always be true. It is however, a good thing to be able to say that the parties concerned with this particular security breach have been forthcoming to the community. A large part of security is just that. Hats off to the debian people.
There would then need to be a vulnerability in apache/httpd to allow a user to execute arbitrary code.
it seems everyones favorite whipping boys did alot of work in finding and fixing this bug. AND THEY SHARED THE INFO, who says corporate linux is evil now!@
For The Best Jazz/Hip-hop fusion > COlD DUCK
Several million others that I missed, which courteous slashdotters will point out.
I'm sorry Dave, I can't do that...
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
Or perhaps "she" sniffed a password?
I refuse to believe that the really hot, Debian-using, password-sniffing, root-exploiting geek girl is a myth.
I have found there are just two ways to go.
It all comes down to livin' fast or dyin' slow. -REK, Jr.
Any word on the parties behind the attack?
The question remains, who is targetting Open Source? With this being the latest in several high-profile attacks, the evidence would suggest a determined effort is under way to put egg on the Open Source face.
Who? Why?
Anything is possible given time and money.
This is a local exploit, it can't be used until you have a shell. Debian had the misfortune of having a developer's password stolen and used to get a shell, other distros would have to have similar problems with either passwords or network accessable services.
This isn't a special situation, everyone should be checking the integrity of their servers periodically anyway.
Pretty good if you know how to spice it right. The trick is, knowing you've got crow to eat. How's that mystery meat you're chewing on?
(there's a joke about feeding trolls to be made in this somewhere)
Great..... there goes my uptime.....
If I have to reboot more than once per year, I'm switching to Windows.
me@spyder:~$ w
17:26:24 up 168 days, 5:52, 5 users, load average: 0.70, 0.78, 1.59
D'oh. Well what to do....
--toby
Comparing it to Windows will be a moot point, since El Dorado is going to have a 40% larger code base than XP.
But according to most admins here, they don't immediately apply Microsoft patches, so they can do their little "tests" to make sure everything keeps running fine.
But when Linux has a kernel exploit and is patched, people will point to that--"But it's already patched! Download the new kernel!"
"Sufferin' succotash."
Every time there's some sort of compromise on a high-profile Linux network, some idiot tries to implicate Microsoft on the basis of idle speculation.
Why it continues to be modded up as "Insightful" every time, I'll never know. Honestly, what insight was gleamed by this post?
"Sufferin' succotash."
Nobody says it's OK. This is a serious problem. I was just saying that this problem was not Debian-specific, i.e. it could have happened on any other Box running a (by that time) released Linux kernel, as long as the attacker had local access.
what's Debian without the Linux kernel?
Not much. But note that Debian also works on Debian (GNU/)*BSD and Debian GNU/Hurd, not only Debian GNU/Linux.
Michael
You know, people hack things. Kiddies hack servers.
Why does it always have to be a "determined effort" against Open Source? Honestly...how paranoid do you have to be to think that? You do realize a lot of idiot kiddie (and professional) hackers are aware of Linux.
Let me put your underlying implication to rest--no, it wasn't Microsoft. No reason to believe such. It was just some idiot hacker, like it always is.
"Sufferin' succotash."
I just checked the current Red Hat 9 kernel source RPM and it does not have the patch yet [kernel-2.4.20-20.9.src.rpm]. I would expect a new kernel to show up soon though....I hope. The supposed patch which fixed this was in do_brk() [a /. comment further down provides the bk url]
Before you demand humility from the Open Source community you might want to check relative numbers. How many available kernel exploits have been identified over the last 5 years of Linux? How many available kernel exploits have been identified over the last 5 years of Windows?
It's not really a fair polling system, though. Microsoft can spend millions to squelch the public notification of any severe exploits if they need to. The fact is that unless we're actually the ones writing exploits we'd never know.
There are some basic principles which point towards secure code. Proper flowcharting. Proper logic design. Efficient code. Time and again Microsoft has demonstrated its disregard for proper flowcharting and logic design (eg. "We have a deadline to meet. Make that code work any way you can so we can put this sh*t on the shelves and sell it!") and the code is blatantly bloated. Where Microsoft fails on all three criteria Linux makes a comprehensive effort of achievement. It may not be very technical or factually based but, in the absence of any real or reliable numbers, it's the best benchmark to use to compare the two.
+++ATHZ 99:5:80
Part of what you say is right... However, the difference is that with Windows, what you hear about are *remote* holes, while in this case, it's a *local* hole. That makes a big difference. Local holes are frequent on any OS and regardless of what you do, a rogue local user can always do bad things. Remote holes are much worse, as anyone can attack your machine, not only local users. There have been very few remote holes with Linux (at least compared to Windows).
Opus: the Swiss army knife of audio codec
You're right, of course. This is an instance of a real security hole discovered in the kernel itself, and not of the garden-variety "could-theoretically-happen-under-XYZ-circumstance s" type you usually see with Linux.
So that makes...hmmm...one. One real hole in the Linux kernel this year.
Congratulations! You've proven that Linux isn't perfect. Which those of us who aren't trolls or delusional already know.
Exactly what crow is that?
Would that be that a legitamate error was found verified and fixed in public in just about two weeks with no hiding or spin?
If Windows had a memory allocation error (application memory space being the thing controled by brk) of this sort would they allow it to be publicized?
Once they made the "patch" available, would you be able to apply it to every past version of Windows?
Would you be able to verify that the patch was applied to windows?
If Debain's FTP server had been running IIS and windows, what kind of forensic annalysis would have been done, and how LIKELY is it that the *SINGLE* *INCIDENT* compromise would have lead to a complete and detailed report from Microsoft, and a fix?
The "linux is more secure" argument is not (truthfully) based on the idea that linux is inherently error free. It is based on the idea that the persons experiencing the problems can determine what those probems actually are; come up with a fix; have that fix reviewed [and installed] (by all who care) *WITHOUT* needing to waking some sleeping-bear corporations nacient interest in the suffering of their lowly surfs... er... "customers".
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Good luck!
Use ISO 8601 dates [YYYY-MM-DD]
Right. So instead of stealing the password the intruder has to take the extraordinary step of stealing the key. And you've got an even worse problem in the general case when dealing with keys, because you have a hard time enforcing things like password expiration (just how long can someone use that stolen key to get into your system?)
What I find intriguing is that those fine folks at Debian have come this far at detecting the exploit and tracking down the who's and why's (with the who's still being left undecided for the public, anyway).
Honestly, if I were smart enough to sniff a password, I'd also be smart enough not to let anyone know I've sniffed. Still, the folks at Debian were able to blame the unpriviledged account part on a sniffed password. Now how do you gain evidence for something like that?
Likewise, if I'd be smart enough to gain local root access by flipping the kernel, I would also be smart enough to ditch the binary with which I did that. Nevertheless, though after a thorough research, the Debian team has found the binary and managed to understand its potentials.
But still, what intrigues me the most is that they have found out that they were hijacked in the first place. Now I have a rock solid system for that at home, which is an 8 Mb RAM Sparc Classic, which starts to trash so hard at the least of activity, that I would well be alarmed if someone else than me was using that machine for whatever purposes. But as I may assume that those Debian machines weren't that low-end, how could you ever expect to know when you have been exploited?
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
Windows has tons of local root exploits, which nobody is bothering to fix because they're too busy patching the remote exploits.
If Windows had a bug like this, it wouldn't be news. Microsoft hardly even tries to defend against such things. The only reason this is newsworthy is because Linux attempts to set a higher standard.
"
How many available kernel exploits have been identified over the last 5 years of Windows?
"
Sorry - Linux loses here. They don't call it a kernel exploit in windows. It's always an exploit in a separate subsystem instead.
Shhhh! Don't go telling everyone that the subsystem has access to every byte of RAM, and every I/O port, as that would spoil the fun.
YAW.
Your head of state is a corrupt weasel, I hope you're happy.
The worst Linux exploit of the year: an obscure kernel vulnerability that allowed one person to gain control of one box, disrupting one small OS group for a few days.
The worst Windows exploit of the year: a hole in the RPC services (which you can't turn off) that allowed a worm to gain control of millions of Windows boxes, disrupting the entire internet.
How does this make Linux equally bad as Windows, then?
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
A couple of points...
1) Note that of the 15 listed advisories:
5 are the same BIND DOS vulnerability
2 (or 3 if you count Turbolinux's mega-update) are the same Ethereal vulnerability (DOS, possible arbitrary code)
2 are the same stunnel hijacking vulernability
2) None of these vulnerabilities lead to a remote exploit (although it could be argued one might be able to create a favorable condition with the ethereal issue)
Sure - Linux runs buggy code too. If that's your point, make it. But this hardly seems to be a suitable response to the parent's (semi-trollish) comment on MS' run of remote exploits.
You can turn off RPC (aka DCOM) with this utility: http://grc.com/dcom/
No, I think Debian is still using kernel 2.0.0. There is going to be a new Debian release "any day now."
1) It's not obscure anymore
2) You don't know how many persons used this exploit to take over Linux servers
3) You don't know how many Linux servers were taken over by this exploit
4) Yes, When an exploit hits Windows, it hits many more machines, because there's many more Windows boxes than Linux
5) You obviously have missed all the remote exploits affecting tons of server software on Linux this year(openssh, apache, etc...), any of these could lead to owning the whole machine when used with this local exploit
an obscure kernel vulnerability that allowed one person to gain control of one box
This statement is missing a qualifier that is very important: 'That we know of so far'. How do you know that there is only one person who has the exploit? How do you know that said person only rooted the Debian boxes. How do you know that a larger group of people don't have this exploit and don't already own a flotilla of zombie systems? How do you know that your box isn't owned by such a group at this very moment?
It is these "obscure kernel vulnerabilities", that we assume no one has an exploit for, that are the most dangerous of all. Vulnerabilities of this type allow very highly skilled crackers (with intentions unknown) to own countless systems and do what they will for extended periods of time without detection. Debian thinks that this is weeks old. Suppose that this is only the cracker's latest version of the exploit and that previous versions haven't owned those machines for months or years?
Um no.
First the exploit compromised one of the largest linux distribution and potentially they could have put trojan horses in all our packages and we would really be up shit river when that happens.
Secondly, we are no longer getting package updates so they have successfully stopped Debian development while they patch all this.
Although it's not in the scale of windows, if GNU/Linux had larger marketshare this would have been a big deal.
sri
I haven't clicked the link in your sig because:
1. It's a timyurl link(ie. probably goatse), and
2. The description sounds like goatse as well.
"We have got to make Stan understand the importance of voting, because he'll definitely vote for our guy." - South Park
Having looking at both sources for linux and BSD, I think that BSD is better written in total. That isn't to say that there are no ugly parts in BSD, or no nicer parts in linux, just as a whole BSD is nicer.
To save you some time I present the next 3 replys to this post.
Is not
Is too
Is Not
Screw Linux! :)
[root@balder toor]# uname -a;uptime
SunOS balder 5.8 Generic_108528-07 sun4u sparc SUNW,Ultra-250
2:42am up 864 day(s), 7:26, 2 users, load average: 0.07, 0.06, 0.05
[root@balder toor]#
What about 2.2.x series kernels, is there a similar patch?
The real "Libtards" are the Libertarians!
Here is a tool that may have been used.
Grab it here
It was introduced in 2.4.23-pre7, disguised as "Add TASK_SIZE check to do_brk()" in the changelog.
If you aren't averse to compiling your own kernel, the fix is a really easy two line patch. Just add the following to mm/mmap.c at line 1047 (immediately after "if (!len) return addr;")
if ((addr + len) > TASK_SIZE || (addr + len) < addr))return -EINVAL;
I'm enjoying the thrill of compiling patched kernels on two different machines as I write this. Thank goodness for Debian's make-kpkg.
- Kevin B. McCarty
Say it with me ....
There is no such thing as Utopian security. IF your hooked in your vulnerable. period.
I don't know why people make such a big deal out of security for computers. Think about it. In real life things aren't very secure, I could break into most homes and steal things, or break things if i wanted to. but I don't. Why ? the threat of punishment, and not-so-common sense.
If your a person who has deviant desires why wouldn't you break into a house ? VISIBLE security that would make punishment (ie jail) more likely would be the major reason. its not that the house is burglar proof, its that society has come to deal with criminals in the most effective way possible, and it doesn't usually hinder the average person. I think this is what we are lacking with computers, a clear cut enforcer. a "police" type body that could enforce laws such as "cracking and entering". and programs similar to an ADT-type of alarm system. We need a real solution. and Utopian code is not it. and making absurd laws are not it either.
"Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe." --Albert Einstein
Imagine there is a buffer overflow in the kernel's brk() implementation that nobody knows about. What kind of security measures (other than finding the bug and fixing it) could prevent that buffer overflow from being exploited by an attacker?
When that question has been answered, go implement the answer, and this won't happen again.
Installed the Bubblemon yet?
What ever happened to Scrappy Doo?
You need to watch the recent (well, couple years now I guess) Scooby Doo live-action/CGI movie. It explains all.
(And my excuse is that I have kids -- I rented the DVD for them. That's my story and I'm sticking to it.)
-- Alastair