![Debian Debian](http://a.fsdn.com/sd/topics/debian_64.png)
![Software Software](http://a.fsdn.com/sd/topics/software_64.png)
![Linux Linux](http://a.fsdn.com/sd/topics/linux_64.png)
Kernel Exploit Cause Of Debian Compromise 673
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."
A shift of focus (Score:5, Interesting)
Re:A shift of focus (Score:5, Funny)
It's fun to see how security research shifted from applications to kernels lately.
Fun!? You must be Klingon.
Re:A shift of focus (Score:5, Funny)
Today is a good day to get rooted.
Re:A shift of focus (Score:5, Informative)
Traditional local root exploits are all based on overflowing a setuid application or server. But if the box doesn't have any vulnerable apps installed, the attacker is SOL. However, if the kernel itself is exploitable, it no longer matters whether those setuid programs are present. All you need is to somehow acquire local access, and wham, you are root.
To summarize, kernel exploits are very convenient for turning local user account compromises into full-blown root compromises.
Re:A shift of focus (Score:5, Funny)
does this code belong to sco?
Re:A shift of focus (Score:5, Interesting)
We should point out that you're talking about common kernels like Linux today, not that this must apply to any OS kernel. For example, if the kernel verifies the binaries it runs using digital signatures, then it can refuse to run unsigned binaries. The cracker's problem then becomes how to get an existing userland program (compiled by the trusted administrator) to issue the kernel call that results in the exploit, which is a much harder problem. A program may not ever make that system call, or may check its input so that you can't make it do the system call with (presumably) invalid parameters. In most cases, I expect that this means you have to insert a backdoor into a common program and wait for the trusted administrator to compile it for you.
This sort of security is probably overkill and too tedious for a desktop box, but not unreasonable for a server which should only have a few programs installed and running anyway.
Re:A shift of focus (Score:5, Funny)
Re:A shift of focus (Score:3, Interesting)
The reason this isn't done more often, is that it's a bit of a hassle for the power users.
Re:A shift of focus (Score:5, Informative)
Re:A shift of focus (Score:5, Informative)
This thread [debian.org] on the Debian mailing lists talks about this issue, and a poster in this thread notes that SE Linux is capable of closing this hole (with example). I don't recall offhand what tools are available in grsecurity (www.grsecurity.net) to address this issue; check out the grsec mailing lists for more info.
Re:A shift of focus (Score:3, Insightful)
Sorry, I must have been vague, although some responses have grasped the main point of what I'm talking about.
The binaries are signed by the local root user (preferably on a separate box), at install time. The public key is installed in the kernel. This is about the root user preventing the box from running anything he did not install, not for the program's copyright owner or whoever else to control if it can run. As you can see, this has little to do with DRM, wh
Re:A shift of focus (Score:3, Insightful)
I disagree with your assessment. It depends on how the separation of mechanism and policy are implemented in the system. The "fear zone" you describe could only apply to a proprietary, binary-distributed system. Consider an environment where the system installer (call 'em the Admin) can install a public key at system setup time. Then, assuming the correctness of the signing system, the
Re:A shift of focus (Score:4, Insightful)
A desktop system is exposed to tons of potentially hostile data. Strings are like acid, and a complex language like HTML is just asking for trouble.
Don't get me wrong, OpenBSD is waaay into diminishing returns territory as far as security goes, but there's a few things that could be done to get 90% of the benefits, eg propolice in the kernel and W^X.
Re:A shift of focus (Score:4, Interesting)
It's also possible to use SELinux [nsa.gov]. With this module you can in details give permissions to any object in the system. A web server would not be able for example to run
Re:A shift of focus (Score:3, Interesting)
In a life long ago, I used a Multics system which was running AIM, the kind of military-grade security that's in NSA's Linux, and couldn't even tell it was in place. The sysadmins could, but us developers only saw the usual group-like facilities.
This is prefectly reasonable for a machine that's hosting my current personal projects along with my homework (;-))
--dave (DRBr
Re:A shift of focus (Score:3, Interesting)
I suggest you consider the solution again. The underlying bug (kernel buffer overflow, for instance) doesn't disappear. It's just much harder to exploit. In an unsigned system, it's a pretty trivial task to download a binary that makes the "proper" kernel call. If a compiler is installed, you can even just type in a program.
On the other hand, on a signed system the only way is to get
Kicking it up a notch. (Score:5, Funny)
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)
Re:My my my, yet another Linux bug. (Score:3, Insightful)
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.
Shows the dangers of C (Score:4, Funny)
Re:Shows the dangers of C (Score:3, Redundant)
Get real! Everyone knows kernels should be coded in COBOL!
Well then they'd better get some help (Score:5, Funny)
You appear to be trying to write a kernel. Do you want to:
Re:Wow, a Clippy joke (Score:3, Informative)
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.)
Re:Shows the dangers of C (Score:5, Funny)
Re:Shows the dangers of C (Score:5, Funny)
If you can't read your own code who else can..
Re:Shows the dangers of C (Score:3, Informative)
You're on the right track. Now, if you think a little further along the same lines, you'll see that you are much better off implementing safety once, in a single place in the runtime, rather than trying to implement it in user code in 6 million lines of kernel code. It's called "reuse", "abstraction" and "encapsulation", and it's as important for safety as it is for anything else.
In some situ
what kind of person... (Score:5, Funny)
Re:what kind of person... (Score:4, Informative)
spammers [bbc.co.uk]
People who expect to make money by hacking systems and using them to send millions of unsolicited emails.
Re:what kind of person... (Score:5, Informative)
ashridah
Re:what kind of person... (Score:5, Insightful)
What kind of person spends that much time trying to find exploits in operating system kernels?
The kernel developers, i.e., Andrew Morton. Good for him, too.
There *was* a patch before the Debian systems were compromised. Hopefully in the future these things will be given more attention before they blow up.
Re:Well, well, well... (Score:3, Insightful)
What Crow? (Score:5, Interesting)
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".
Wrong (Score:3, Insightful)
Good luck!
Re:Well, well, well... (Score:5, Insightful)
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?
Re:Well, well, well... (Score:4, Insightful)
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
Re:Well, well, well... (Score:3, Insightful)
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 th
Re:Well, well, well... (Score:5, Insightful)
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
Re:Well, well, well... (Score:5, Insightful)
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.
Userland exploits (Score:5, Funny)
Yup (Score:5, Funny)
Re:Userland exploits (Score:4, Insightful)
Re:Hmm, Methinks I've Heard this theme before (Score:5, Funny)
I'm sorry Dave, I can't do that...
Hurray for the Debian Security Team! (Score:3, Informative)
Hats off to the Debian Security Team.
Re:Hurray for the Debian Security Team! (Score:4, Insightful)
Re:Hurray for the Debian Security Team! (Score:3, Informative)
Re:Hurray for the Debian Security Team! (Score:5, Informative)
Quoting the Bugtraq post:
This problem was found in September by Andrew Morton, but unfortunately that was too late for the 2.4.22 kernel release.
Re:Hurray for the Debian Security Team! (Score:4, Insightful)
I'm guessing it was found and corrected, as a bug, but not thought to be exploitable, therefore no security announcement[0]. Later on, when debian.org got cracked, someone put two and two together and made the security announcement. I must admit, it seemed fairly weird to me for a long time, and I thought up a few lovely conspiracy theories, but in the end I think the simple oversight scenario is the most likely.
[0] After all, plenty of bugs get fixed in the kernel without being specially announced. If it was subtle someone probably just overlooked the fact that this particular bug was more problematic than any of the others fixed in that patch.
Re:Hurray for the Debian Security Team! (Score:3, Informative)
from the article: "This problem was found in September by Andrew Morton, but unfortunately that was too late for the 2.4.22 kernel release." Good work by the Debian team in catching it before REAL problems ensued.
Hats off to Redhat and SuSe for reversing the code.
How did they get in to run a userspace util? (Score:2)
That still doesn't get you into the box; you still need to run something in userspace- and thus I think claiming(based solely upon the evidence presented in the /. story) that the compromise was not Debian specific to be premature. Has it been established how access was obtained into the
Re:How did they get in to run a userspace util? (Score:3, Informative)
Re:How did they get in to run a userspace util? (Score:5, Funny)
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.
RTFA (Score:5, Informative)
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.
Will redhat provide an rpm??? (Score:5, Interesting)
Re:Will redhat provide an rpm??? (Score:3, Informative)
Just wondering if they will still support us lowly 7.3 and 8.0 users anymore with a fix for this.
Red Hat is supporting [redhat.com] these releases until the end of this year, so I'd expect them to.
Not yet (Score:5, Interesting)
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]
So it sounds like.... (Score:5, Informative)
Time for better security. (Score:5, Insightful)
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.
Re:Time for better security. (Score:3, Interesting)
Strictly true, but there has been one remote hole and many local root holes. Remote hole + local root hole = remote root hole.
I'm not denying OpenBSD's superiority, but its security record isn't that much better than that of the other BSDs.
Re:Time for better security. (Score:5, Interesting)
The strength of OpenBSD is that people continously audit the code and implement preventive stuff like privilege separation to reduce the risks in case of a vulnerability.
On the other hand, the code of BSD kernels is a real mess. Some parts are really tricky, with glue between historic and new code and a lot of ugly, possible unsafe macros everywhere. The Linux kernel framework is way cleaner and more robust. When something goes wrong in a kernel thread, it can almost always properly recover and not just go to panic().
And Linux has also some barriers like SELinux that theorically renders uncommon situations not exploitable. Theorically, because there can still be bugs in SELinux or other parts of the kernel that would bypass it.
The "barriers" approach, although described as useless by some people is, in a real world, very efficient. Grsecurity (or recent OpenBSD with PaX and co) and SELinux make it very difficult to write reliable exploits. Still if an exploit would work, it will only work after having filled gigabytes of log files, giving a change to system administrators to take an action on time.
The cons of the "barriers" approach is that it cures the implications of a problem, not the cause. The bug is still there, but instead of being exploitable to execute arbitrary code, it crashes the process (eventually immediately restarted with a tool like Monit or Supervise).
The OpenBSD auditing approach aims at curing the bug itself, thus not causing any crash.
Both approaches are actually complementary, but still not 100% efficient.
The only way to make reliable and secure (even from a theoric point of view) is to prove the code. Unfortunately it's not a trivial task and it can't be made upon an existing unix-like base.
But if you never heard about it, have a look at the very promizing EROS Project
http://www.eros-os.org/
Re:Time for better security. (Score:3, Insightful)
And in this case, SELinux wouldn't have helped, because the bug let user space programs into the kernel's memory space, and once that happens all bets are off, much like what would happen if any program could write to /dev/kmem.
I think BSD is better written... (Score:4, Interesting)
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
Re:Time for better security. (Score:5, Informative)
I repeat, I'm not trying to bash OpenBSD. Just trying to bring a little balance to the arguement. OpenBSD is an excellent choice for an operating system, but it's designed by humans. Humans make mistakes.
The real flaw in what happened with this exploit is that there were no backport patches created. When the ptrace vuln came out I was able to patch my 2.4.19 and 2.4.20 systems right away, I didn't have to wait for the next release to come out in order to get a working fix.
This should trun into a plea to the developers, if a bug is discovered through the normal course of development that is potentially serious enough for older kernels, it should be brought out into the open and the fix backported.
Re:Time for better security. (Score:4, Funny)
Never EVER put these words together. It's like keeping the Bible next to the Koran. You'll never know just when they will auto-ignite!
Re:Time for better security. (Score:3, Insightful)
Re:Time for better security. (Score:4, Insightful)
You appearantly don't pay much attention to what your read then, since for OpenBSD 3.4 there are two security fixes. One local and one remote denial of service. One of the security fixes are only relevant for i386.
http://openbsd.org/errata.html
Re:Time for better security. (Score:5, Interesting)
You know, when I install a computer, I consider the "install" to be the files installed on my hard drive. "/bin/ls" is part of the "install." "/sbin/ifconfig" is part of the "install." "/usr/libexec/ftpd" is part of the "install."
Apparently, however, the OpenBSD developers disagree. Something has to actually be running to be part of the "install." Thus, by their definition, none of those programs are part of the "install."
Good thing, too. Because
Jeremy
Re:Time for better security. (Score:4, Insightful)
Second, that "standard install" has most of the features turned off... No Apache, etc... I don't even know if SSHD is on by default. I mean, they could have zero remote root compromises if their standard install didn't include network drivers.
I know that OpenBSD can't possible comb every line of apache and all the other contrib software ten times over, but this would be a problem for the Debian folks too.
Re:Time for better security. (Score:4, Informative)
Re:Time for better security. (Score:3, Insightful)
Okay, OpenBSD is nowhere near that bad, but the default install doesn't actually do that mcuh - you have to turn on _some_ services if you want to do anything, and I presume that doesn't caount as "default install"?
Jedidiah
Re:Time for better security. (Score:4, Insightful)
Define useless. It comes with a compiler, make & other build tools, and an ftp client. What more would a real unix user need?
The kernel patch... (Score:5, Informative)
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...
Re:The kernel patch... (Score:5, Insightful)
If fixes are made which affect security, the ChangeLog should clearly spell out that it was a SECURITY fix. I guess people don't want to admit that they have found a security problem...
Re:The kernel patch... (Score:3, Informative)
Re:The kernel patch... (Score:3, Funny)
I'd say someone figured it out at least a week ago [debian.org].
There goes my Saturday (Score:5, Funny)
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!
Re:There goes my Saturday (Score:3, Insightful)
Comment removed (Score:5, Insightful)
Re:so are other distros possible infected? (Score:5, Informative)
This isn't a special situation, everyone should be checking the integrity of their servers periodically anyway.
Re:so are other distros possible infected? (Score:3, Insightful)
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?)
red hat and SUSE to the rescue (Score:3, Insightful)
The real question remains.... (Score:4, Interesting)
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?
Um, no (Score:4, Insightful)
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.
Re:The real question remains.... (Score:3, Informative)
This has been confirmed in an earlier post.
So which individual was sending passwords in the clear?
Exactly how the attacker managed to get the password is unknown so far. It suffices to say that he got the password and thus access to the machines.
And if it's a Debian developer who's done this
There are far easier ways for Debian Developers to mess up Debian. That's why there are the tough entry exams, aka th
Up 107 days... (Score:5, Funny)
Great..... there goes my uptime.....
If I have to reboot more than once per year, I'm switching to Windows.
I feel your pain.... (Score:3, Funny)
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
Mysteries of good system administration (Score:5, Interesting)
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?
Re:Mysteries of good system administration (Score:3, Interesting)
What release did it APPEAR? (Score:3, Interesting)
Re:What release did it APPEAR? (Score:3, Insightful)
I wrote some exploit code for the 2.4 kernel, it didn't work on 2.2, so maybe 2.2 never had this vulnurability.
How to decrypt a burneye encrypted exploit? (Score:3, Interesting)
Here [securiteam.com] is a tool that may have been used.
Re:How to decrypt a burneye encrypted exploit? (Score:4, Informative)
Proof-of-concept exploit code (Score:3, Informative)
Grab it here [linuxfromscratch.org]
For the Security ANAL. (Score:3, Interesting)
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.
Learning from your mistakes (Score:3, Insightful)
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.
Re:How does this compare... (Score:3, Insightful)
Re:How does this compare... (Score:4, Insightful)
Actually the Windows story was about how Microsoft had not patched an exploit they had known about for months.
This Linux exploit had ALREADY been patched.
Double standards (Score:3, Interesting)
But when Linux has a kernel exploit and is patched, people will point to that--"But it's already patched! Download the new kernel!"
Re:How does this compare... (Score:4, Insightful)
Or maybe it should be a story about how Linux users don't shoot the messenger. "They shouldn't have made the exploit known before the patch was available." -- the oft heard commercial software providers' complaint about how irresponsible it is to exploit a system before the patch is available.
Agreed (Score:5, Insightful)
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.
Re:This smells like the work of... (Score:5, Interesting)
Why it continues to be modded up as "Insightful" every time, I'll never know. Honestly, what insight was gleamed by this post?
Re:It's Linux's fault not Debian(!?) (Score:3, Insightful)
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