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.
Fark. This seems to be a local exploit though. Whose the naughty one that did it? We can't have rogue members in our proud Debian society now can we? Come on, take it like a man.
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.
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 machine in the first place?
Please help metamoderate.
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:
The management of the incedent seems very professional to me. Thanks to all the people who had a lot of work because of this. They keept the reputation of debian up! Which is a good thing since this is my favorite distribution. :)
Disclaimer i'm no debian devel
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.
So the exploit was known for a long time, and the next kernel version, 2.4.23, came out on 2003-11-28! This is dangerous. They shouldn't wait for the next kernel version to release a security-related patch.
This does not affect OpenBSD. Smart admins can sleep well tonight.
Hell, who cares, OpenBSD is dying. In fact, in Soviet Russia it's already dead...
Tubal-Cain smokes the white owl.
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...
<sarcasm>Come on now, as any slashdot reader knows, BSD is dead.</sarcasm>
LONG LIVE BSD!
--Mod me up, mod me down, they're your points to waste...
I used to wonder what was so holy about a silent night, now I have a child.
You mean the machines will try to take over from the humans?
* The Matrix (V1.0 - V3.0)
* Terminator (V1.0 - V3.0)
* Several million others that I missed, which courteous slashdotters will point out.
openBSD did have one vurnability in the standard install, the openSSH issue of about a year ago.
l oc .txt
according to the site:http://www.openbsd.org/
Only one remote hole in the default install, in more than 7 years!
http://www.openbsd.org/advisories/ssh_channelal
But I suppose you could argue that openSSH, even if it was sponsored in part by the OpenBSD team, isn't really part of the OS, or at least part of the Kernal.
Of course, this is far better than just about any other OS.
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.
Not necessarily. For all we know the Debian servers could have been h@x0r3d simply because they were a high-profile target in the OSS world.
Although I do agree with the other poster who said that perhaps the cracker got the idea to try the exploit by reading the ChangeLog. Not that I'm condemning the use of known stable kernels on mision-critical servers or anything - but perhaps something like this would have warranted a kernel change?
SCREW THE ADS! http://adblock.mozdev.org/ Proud user of teh Fox of Fire - Registered Linux User #289618
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
In post Soviet Russia OpenBSD runs firewalls!!!!
They aren't "possibly infected", they are "definitely vulnerable", as long as they use a kernel < 2.4.23, which are probably all of them. Mandrake has updated kernel packages, for others, you probably should build your own kernel or take your boxes offline until new packages are available (or make damn sure that no malicious user can get a local shell). I'd expect updates for most distros rather soon now, however. You decide.
Programming can be fun again. Film at 11.
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.
(A: Slashdot weenies)
Programming can be fun again. Film at 11.
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.
I knew I was forgetting something. Excuse me If I can't see my own bloody signature.
/*RetroGeek*
echo "* 2001: A Space Odessy" >> comment
rm -rf
# Who, me?
That's the stupidest thing I've heard in a while - I doubt anyone at MS even knows what debian is (unless it's a geek, who's just playing with it at home).
sic transit gloria mundi
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.
No I work for Mandrake, and no, we haven't checked our machines. What's this Linux-thingy you're talking about?
--jackson-5.
http://www.varnamognagare.com/calle/runken.mpeg
I verified it, it's the right one.
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."
It could simply have been opportunity; he (or she, for that matter) could simply have sniffed the password by luck/chance and then cracked Debian from there.
Of course with most Windows subsystems having administrator or SYSTEM access, what's the difference?
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."
It should be noted that this was not remote exploit like all the recent MS exploits. This still requires access to the box.
The people at debian caught on, but what about at other distros? Have they made sure that their machines havn't been exploited and no trojan type code was introduced?
Security is more than just patching the systems, have a secure internal network and a good security policy to live by, and the risk of exploits happening inside goes down. If you can't connect to any machine (and thus not log on to it), you won't have the ability to exploit the vulnerability either.
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]
I wonder when the Slashdot community will stop berating Microsoft, Debian, and whoever for security holes, and instead of heaping scorn on the real culprits: the exploiters (sounds like the title of a Matt Helm novel).
Any complex program is going to have security holes; as the software evolves, new weaknesses will appear as old ones are eliminated. The way this community acts, they throw the victim in jail instead of the criminal. Leaving my door unlocked may be stupid, but it also isn't an open invitation to burglars and vandals.
I'm no fan of Microsoft, and I run Debian -- neither should be blamed for the ill-behavior of nasty little criminals who revel in destruction and mayhem.
All about me
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
Actually, my first reaction was "Blast, a kernel exploit. But at least they've patched it." When I see Microsoft holes reported I think "Hah, more proof that MS is incompetent! And they won't be patching it for a while to come!"
People see what they want to see. I don't see anti-Microsoft vocalists as stupid because of stories like this. I see them as heralders of the truth. But of course I'm biased, so take what I say with a grain of salt: I'm an MCP.
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
So what you are saying is that all the exploits in IIS are written by the Apache authors? And Linus is responsible for exploits in windows?
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
Yes you're right. Anybody who writes code can write security bugs equally well; doesn't matter if you do it in the open or locked up in some Redmond cubicle. And although Open Source software in general may be more secure, the Open Source model does not itself prevent security bugs (nor does the proprietary model).
But the most important part of being Open Source (err Free Software to be more correct), is the Open part. That's not primarily and advantage for the developers, but for users! Thanks to it being open, I personally have the ability to apply the two-line patch myself...oh, and knowing what those two lines are. I don't have to wait on Redmond to do it, if ever, or worry about what kind of mandatory DRM feature comes hidden with the security patch.
It ain't the jokes themselves, but the relevance.
It is still all too relevant. They still include that POS (piece of software) in Office.
Good luck!
Use ISO 8601 dates [YYYY-MM-DD]
So Microsoft is just targeting Debian Now?
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]
You're taking this way out of context. You sound like you've been wanting to have something to fry Debian's feet with for a long time.
Think of things this way. This was one attack that was identified and fixed in light speed time. If this were any Windows product it would still make for a prime exploit two years from now. Script-kiddies would have it packaged into an email and sent around to everyone using Outlook. Parents would be compromised because their children wouldn't know any better. Cell phone networks would be done. We might even have experienced another power grid failure.
So chill off for a few moments. It was a handful of Debian servers and the entire community knew about it right away. There was no corporate coverup and no massive e-mail sweep.
+++ATHZ 99:5:80
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.
Feed the trolls. You counted Bind 5 times, before the page chopped off your comment.
Get your own free personal location tracker
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!
The sad thing about this case is that the way the story has broken before all the parties had fixed up kernels out (I think we're still waiting on RedHat dunno about SuSE). I kind of wish they had held out another day but maybe they had waited long enough already. Kernel exploits are nothing new but they sure are unpleasent.
Please tell me you're making a terminology error. Flowcharting, per se, was discounted as nonproductive eons ago. I think you're referring to class diagramming and such as exemplified by the UML, but that is a long stretch from code flowcharting.
Yessir, there are actually critical bugs in open source software. *SHOCK* *HORROR*. That's the point. we have those lists so patches can be made, and updates can be applied. Several of those vulns are repeats, and none but this debian one is really critical. Follow up on those vulns and see how bad they really are
Who is this Anonymous Coward character, how does he post so much, and why is he always such a whore?
Windows is not.
Window$ doesn't have a kernel; a rat's nest, maybe, but certainly not a kernel...
t_t_b
I'm on PJ's "enemies" list! Are you?
I saw what was probably my first BSOD under Windows XP recently. My neighbor's box would begin to show the loading sequence for windows then BSOD complaining about an illegal instruction in the process1 loader or something like that. It turned out that it was a toasted hd, but still, XP does BSOD.
t'nera semordnilap
I'm not making an error. It's not my fault that the terminology has been changed because people have become intimidated by the size of their own code.
When I write something I still flowchart it. My logic is flawless.
+++ATHZ 99:5:80
Does anyone know which pre the fix might be in? I ask as for UML there are some precompiled kernels and just trying to find out if it would be quicker/easier
Rus
Cheap UK and US VPS
11/29/2003 3:45 - SUSE: BIND Negative cache vulnerability and many others
11/29/2003 3:37 - FreeBSD: Bind Negative-cache DOS vulnerability
11/28/2003 12:30 - Trustix: bind Cache poisoning vulnerability
These three vulns are the same thing, regarding one application which may or may not be running on a particular Linux distribution. You can't count these as separate incidents. Going over your list, fully half your "separate incidents" are actually duplicates.
Likewise, let's see how many of these could lead to a root-level compromise...:
Gentoo: Etherial multiple vulnerabilities: Hmm.. maybe this one (but you're probably already running this particular diagnostic utility as root anyway). Incidentally, this is a third-party application that is not included as part of Linux. Ergo, no go.
Gentoo: Libnids remote code execution: Hmmm.. perhaps. It is doubtful, however. You're more likely to just corrupt and drop your connection. Notice the use of the word "probably". That means "possible, but not seen in the wild; patch before someone does come up with a method for attack". Compare and contrast against most (all) Microsoft announcements.
Unfortunately for you, none of the other issues presented here can lead directly to root-level compromise. Instead, an administrator suffering these exploits would simply need to restart the particular service (as opposed to the almost universal need for a wholesale Windows reboot). These issues fall mostly under "irritating" and not "fatal".
In short: BZZZZZZZZZZT. Try again.
You are right, but nevertheless, that remains a possibility. Don't ever underestimate the depths to which amoral businesses with vested interests will go to. Once you think that way, the possibility that the culprit may well be any other Unix vendor muSt be COnsidered. *wink* *wink* *nudge* *nudge*.
When I see Microsoft holes reported I think "Hah, more proof that MS is incompetent! And they won't be patching it for a while to come!"
Aren't most MS holes patches before they get exploited. I seem to remember the Code Red vulnerability being a couple of months old before the systems got hit.
Je ne parle pas francais.
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.
I agree that it does, but generally only in situations just like you described - faulty hardware. It's that with XP they've generally moved to more graceful ways of dealing with problems. These days, a BSOD is about equivalent to a kernel panic under Linux.
Only as long as you don't need anyone to work remotely. Most OSS projects need people to be able to work remotely...
The developer's password was obtained via a trojaned ssh so even if it was a good password, which it likely was, since their box was compromised it didn't matter. Combine that with a local root exploit that was not properly announced and not even in an officially released kernel until Nov 28 (2.4.23) and you end up with the problem Debian had.
Sigh...
.16.21 alas, .16.20 was rebooted last week)
Since we're getting into the dick waving here:
$ uptime
6:21pm up 472 days, 11:09, 1 user, load average: 0.01, 0.01, 0.00
Yes, the load average is low. The CPU is oversized because to build a machine with 10 ethernet interfaces (2 inbuilt and 2 quads) properly in 1U we needed to move to a PE1550.
It is kept busy running iptables, squid, and a number of other protocol conversion thingies.
(to Uberman: it's
I'm sure someone else can trump this.
I'm still going to be bummed when this one needs to be rebooted though.
J
mm/memory.c, (in an older 2.4.20 kernel), we have: ...int make_pages_present(long, long)... ...
if (addr >= end)
BUG();
if (end > vma->vm_end)
BUG();
Which is called in do_mmap as:
make_pages_present(addr, addr+len);
So if a very large len is supposed to overflow and wrap around, what good does that do if it causes the kernel to panic?
Is it a specific value of len > the possible address space of a user process that gets it to kernel memory? Above 3GB or something?
Fuck Beta. Fuck Dice
Anyone know if a gentoo-sources kernel compiled with grsec High Security level is still vulnerable? Maybe some of the memory address space randomisations will help out here - I'm not too sure.
Get your own free personal location tracker
7.3's current kernel (released 8.20.2003) has a patch called "linux-2.4.18-mmap-sem-debug.patch" which appears to address this. Similar releases were made for the new RH Advanced 3.0 series on the same date. The only current RH release that did not have a release on this date was for the RH Advanced 2.1 series, which was just updated today. Sounds like it's been patched already. Don't forget RH's history of back-porting security patches so as not to release bugs. A grep of the SOURCES dir after installing kernel-2.4.20-20.7.src.rpm game the above file and 2 more results: linux-2.4.22-security.patch and linux-2.4.22-security-nptl.patch. Sounds like it's covered. Don't trust me. Check for yourself.
For those interested in keeping up with RH 7.3 next month (only one month left!): Look and help with Fedora Legacy
I am, and always will be, an idiot. Karma: Coma (mostly effected by
Woah, did you think of that all by yourself? Thank you for that WONDERFUL revelation that software is only as secore as the people who write it.
Maybe if M$ didn't make their software insecure by design people wouldn't bash them for insecure softeare.
WOW! Another wonderfully OBVIOUS comment! No shit, Sherlock. No piece of software is perfect, and all OSS people strive to make their software better.
Maybe you wouldn't be called a M$ shill if you weren't one.
#include "sig.h"
You obviously weren't really using Debian, or at least you weren't paying attention when you were. 2.2 is the standard install kernel for woody, but 2.4 is readily available for the install as well (a simple command line option at boot gets it for you), and I can guarantee you that the admins are capable of using it.
"I may not have morals, but I have standards."
Eh? I'm running a nForce2 chipset. No issues. Is this something that automagically happens within the kernel? Or am I failing to enable something to cause this problem? Got a reference?
Explain to me again exactly what Linus has to gain by microsoft failing? or even linux succeeding for that matter. he doesn't exactly get royalties ;)
SQL Server can make XP BSOD quite reliably. It isn't drivers or hardware either - these are WHQL certified drivers on Dell hardware.
I worked out a way to make it BSOD on login once, but then I was playing around with a custom GINA at the time...
Dunno about that. Class diagramming and the UML are object-oriented design methodologies. They aren't of much use when working on structured, C-based projects like an OS kernel.
So instead of stealing the password the intruder has to take the extraordinary step of stealing the key.
Which, of course, is a file, located on a disk or similar medium somewhere - you can't just guess it or sniff a network for it. Furthermore, even when you have the key, you still need the passphrase.
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?)
Well, you could always have an entry in root's crontab to delete a user's ssh keys every so often, forcing them to generate new ones. Of course, they wouldn't be able to login (via ssh) until they did so, so it's not exactly the same. The key-killing script could generate a new key-pair, PGP-encrypt a copy and mail them to a known email address. That way you'd have to compromise the user's email *and* PGP keys to get their ssh keys, which is starting to look like a lot of work.
Don't forget that security is all about making doing something more effort than it's worth - no security is perfect, and very little is impossible, given sufficient resources and skill.
It's official. Most of you are morons.
I could not find mention on Redhat's bugzilla. Do they know about it?
They should know. Quoting...
Study of the exploit by the RedHat and SuSE kernel and security teams...
Do you care about the security of your wireless mouse?
Look at this this.
LaSt YeAr WhEn I wAs HaXoRiNg OuT a PrOgRaM wHiCh Is NoW cAlLeD lInUx SlAcK wArE a CoUpLe Of LaYmUrZ pUt A gUn To My HeAd AnD sAiD tO gIvE tHeM tHe SoUrCe CoDe To ThIs NeW oPeRaTiNg SyStEm (It WaS wRiTtEn In ViSuAl BaSiC)
wtf.n0x.org
RSA and other OneTimeKey based systems look better and better everyday. If you really need security, use a OTK system, among other steps of course. Users will always pick an easy password ( or if you force them to use a hard one, will write it down so as not to forget it ), so don't allow that password to be reused. This also works against sniffed passwords, or keyloggers, or ...
---
Segmentation Fault ( core dumped )
No, linux-2.4.18-mmap-sem-debug.patch does not address this bug. Nothing in that patch touches the do_brk() function in mm/mmap.c.
Red Hat 9, latest released kernel as of today, appears still to have this bug.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
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
sue 'em, I say...
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?
Tsk Tsk.. DMCA violation in progress!
Though on a serious topic.. this is sort of scary that the problem in the kernel made it that far and no one ( except the writer ) seems to have found the 'bug'....
---- Booth was a patriot ----
Is this the infamous p-trace kernel mod exploit? Still, how was the attacker able to spawn a shell and run the binary to elevate his privileges?
Fred
"A fool and his freedom are soon parted"
-RMS
He COULD have done much more damage, but chose to do something rather minor, that would almost surely be noticed..
Sort of like the moron with that windows worm that caused the pc to reboot.. announcing to everyone it was infected BEFORE the payload was sent out days later....
It amazes me that a person that intelligent to pull that of and have that many infected machines ( or potential ) blows it with such stupid stunts...
---- Booth was a patriot ----
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
"Now Mr. Morton, where were you on Wednesday 19th November (2003), at approximately 5pm GMT?"
In front of his computer. Like everyone here.. (somes people were perhaps at the pizza store)
Ploum.net.
He doesn't -- he just feels he's a minority on slashdot and has typical victimitis. "Hmm, got downvoted. Well, must be my sig and those biased /. mods!" (Anyone on /. screaming "BIAS!" is obviously too damn dumb to realize that they're ON SLASHDOT. DUUUH)
"4) Yes, When an exploit hits Windows, it hits many more machines, because there's many more Windows boxes than Linux"
That's news to me. Last time I checked, one of the biggest pieces of the cake *is* taken by Linux: the server market.
Try again.
"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?"
This particular kernel exploit needs a valid user account. If you don't trust your system with your own user accounts, why would you even start caring about obscure kernel bugs?
In that sense I know that my servers are not taken.
What scares me in this entire discussion is the fact that many people seem to completely lose their sense of proportion when it comes to security. The kernel bug itself was not the security hole; it was just one of the possible (and well thought out) points of attack. Anyone with a local account and access to the machine can get it rooted, given enough time and resources.
What failed was Debian's security model, by which a developer's user account was used to gain access. No hacking other than social hacking involved.
Trustix and Mandrake already have fixes out. Also, the Debian announcement credits "the RedHat and SuSE kernel and security teams" for figuring out that the brk() overflow hole was used.
@dna : ~>uptime 3:07pm up 570 days, 22:54, 1 user, load average: 0.45, 0.12, 0.04 @dna : ~>uname -a Linux dna.xxx 2.4.3-12 #1 Fri Jun 8 13:20:17 EDT 2001 alpha unknown It is an alpha box used as a web/mail/file server + running some research tools...I would hate to have to reboot it.
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
12:20:49 up 482 days, 11:19, 1 user, load average: 1.74, 1.33, 1.28
Ah, perhaps you were under the mistaken impression that "sniffing" is something that only happens on the network. It's more common these days to compromise a password at an endpoint (e.g., your user's desktop system) with a tty sniffer or keystroke logger--the password is not typically sniffed from an ssh session on the network, but is easily retrieved from the endpoint. A key stored on the user's disk is going to be just as vulnerable as a password the user types on his keyboard. The passphrase is retrieved in exactly the same way as the password, via a tty or keyboard logger.
Well, there's a terrible idea. You don't need to delete the *key*, you need to delete the authorized_keys. And you don't want to delete all of them, just the one that expires today. And you don't want to really delete it, you just want the user to change it. And you really don't want to accidently wipe out whatever configuration was attached to the key (restricted commands, etc.)
It really isn't, is it.
hahahaha. Now you've added additional levels of security that the user is responsible for, something that user's don't usually do well. (Integrity of the email store, integrity of the gpg key, transmission of the key from wherever they read email to wherever they want the key.)
Watch where you're sticking your misguided yet arrogant platitudes. And don't forget that simple little technical fixes like "just use keys" often turn out to be less simple once someone looks at them more critically.
Now this is a good suggestion. The problem is that it's not really easy to implement. The commercially available stuff (e.g., securid) is prohibitively expensive and, IMO, leads to a single-point-of-failure security infrastructure. The free stuff (e.g., s/key) is a real bear to manage and can lead to even bigger security problems if implemented poorly.
You do understand how public/private keys in SSH work don't you? On second thought, you don't because if you did, you would not have made the comment you made.
The private key, if it is encrypted, is decrypted by the SSH client and then validated against the public key. So please explain how the server knows the private key is encrypted, the passphrase is reasonably strong (not qwerty or gandalf) and has been changed in the last 30 days?
If VISTA is the answer, you didn't understand the question
Whereas your post was modded up to +5, Interesting. (After klicking on Reply, it was at +4, maybe somebody modded you Overrated already.)
There are two hypothesis that come to mind: Either you are karma whoring, or your image of /. moderation is highly biased.
Joachim
People don't write Manifestos any more -- what's going on in this world? [Frank Zappa]
I don't seem to recall mentioning RH 9 specifically in my post, and since I have no 9 boxes left (all of those have Fedora by now) and am only concerned about 7.3, I checked the src.rpm of the latest 7.3 kernel. This is why I say to check for yourself. IANAProgrammer, I just play one at work, and not in C, so it could be taking about dead cows for all I know. I do know how to grep, and the patches I mentioned come from the 7.3 kernel and grep spots matches with do_brk. If they don't fix it in 7.3, I'd take that for an answer, but debunking me for something I didn't say is kind of pointless.
I am, and always will be, an idiot. Karma: Coma (mostly effected by
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]#
Window$ doesn't have a kernel; a rat's nest, maybe, but certainly not a kernel...
Try deleting that "kernel32.dll" file on your Windows machine and see what happens... all OSes have a kernel of some sort.
I think ultimately Clippy is to Microsoft as Scrappy Doo is to Hanna-Barbera. That said, Microsoft did drop him a year or so ago. What ever happened to Scrappy Doo?
You are not alone. This is not normal. None of this is normal.
What about 2.2.x series kernels, is there a similar patch?
The real "Libtards" are the Libertarians!
Comment removed based on user account deletion
The server market is extremely small compared to the desktop market, and Windows owns the desktop market.
...
Windows also has a much bigger chunk of the server market than Linux.
Linux is around 20-25%, Windows is at more than 50%, both are growing, at the expense of the old Unix versions like Solaris, AIX,
Don't make me laugh!
I have yet to see any complicated logic that worked right the first time. I've come very close, with 2 people working on it and no access to the hardware, but it still had bugs -- they just weren't the kind of bugs that took hours of debugging.
Here is a tool that may have been used.
Grab it here
Here's a short little guide to compiling and installing a new Linux kernel
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
"Windows also has a much bigger chunk of the server market than Linux. Linux is around 20-25%, Windows is at more than 50%"
.)
care to back that up with real proof ? (not some marketing release from some microsoft funded company
"Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe." --Albert Einstein
Debian development is still rolling along. The compromise didn't stop the developers. You just won't see new versions posted & distributed until the compromised systems are checked and brought online, and the updated packages pushed out to them.
it is NOT goatse. use mozilla or another tabbed browser and open in a new tab behind. it is a legit link
FWIW, my Nforce2-based board works just dandy with the 2.4.22 kernel, although I needed NVidia's binary package to enable the built in Ethernet port.
Random AC Windows guy said:
"With Linux, you'd have to do one of the following:
a) apply a targeted patch to your code and rebuild
b) find the right package-variant for your packaging system (i.e. Debian deb != Lindows deb, Mandrake RPM != RedHat RPM).
It gets worse with a kernel exploit - GRUB and/or LILO need to be updated for the system to even boot. Geek understand that - but Joe User?"
Joe user understands up2date -u
That takes care of everything, including the bootloader of choice. I use grub on one RH and LiLo on another, and the same command will update both of them! How does it know? Must be Magical..
Now even better:
Avihson Admin understands cron. Cron means never having to type up2date -u
I never lose sleep doing updates, neither do any of my clients.
The latest netrcaft survey lists the following numbers:
Unfortunately there's no OS breakdown. But anyways swissmonkey admits to working for MS. You have to expect him to quote the in house "motivational" stats.
Yep : http://www.entmag.com/news/article.asp?EditorialsI D=5984
55% for Windows
23% for Linux
... hey, it's just as good as Windows!
Since entmag.com doesn't like direct links, go to http://news.com.com/2100-7344-5088233.html , same numbers.
Sorry that doesnt gauge accurately what percentage of servers run what OS. It states what percentage of servers SHIP with X OS, which consequently has diddly squat (despite what billy has you believe) to do with my point. has a matter of fact you couldnt accurately gauge what percentage of servers run what OS since a large percentage of admins block such information.
As an example I have three systems I admin that when I purchased them had fully licensed versions of either NT4 or 2000, (they even still have the stickers on them from the vendor.) however they are currently running redhat es and SuSe AS respectivly. this is not taken into account in those claims, nor could it be since the error pages are customized and the kernels are patched to reply with a fingerprint to match the requesting OS (among other things).
I make no argument that MS probably still has a very large market share in the server arena (~40-60%) however there are a ton of systems running old crufty OS's and obscure OS's as well as unix's and what not. right now Linux and windows probably account for ~80% of the market with unix pulling in the majority of the rest.
"Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe." --Albert Einstein
And why is a method to accomplish this not available from Microsoft themselves?
Pain is merely failure leaving the body
Yes, but when you take into account how many people actually replace the OS on a newly bought server with another one, the number is not significant compared to the total number, that's why this statistic is valid.
Servers are not like desktops, they're not all delivered with Windows installed, you have a large choice between no OS, Linux, Windows, those who choose one OS usually keep the OS.
I work for Sun, yet you dont catch me spewing marketing crap all over the place about Sun.
And taking the above stats into account what percentage of Ms systems run Apache ? even if you figure 40% of the apache total (in this case 27%) you still come up with only 50 percent, figure in people changing error pages adn responses and your at LESS than 50%. which is what i stated in my original post.
*also not to be a major PITA about it or anything but netcraft (or any other webserver survey) is wildly inaccurate and incredibly subjective.
"Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe." --Albert Einstein
Perhaps I should have expressed that differently. Are you saying you use low-level code flowcharting, or the higher-level design diagramming techniques (e.g. structure charts and data flow diagrams for the structured techniques, or the UML et al for the OO techniques)? If you're doing low-level code flowcharting (the classic sense of 'flowcharting'), then you're a rarity, my friend. I don't think even the heavy Software Engineering types (who seem to love diagrams of all sorts) low-level flowchart every line of code they write.
For structured code, structured design diagrams (data-flow charts, structure charts) might be useful, but that's still pretty high-level compared to the classic sense of 'flowcharting'.
If for some reason you don't feel like rebooting just yet, a friend and I wrote a little kernel module which puts a wrapper around sys_brk() which should prevent this vulnerability from being exploited.
I'm no kernel guru, so if this breaks, you own the pieces... But it's fairly simple code.
"Words have meaning, and names have power." -- Lorien
pointing out the obvious--operating systems are as secure as their admins/makers
The recent exploit is a counter-example, unless you contend that Debian stayed secure because of the skill of its administrators.
It'd be nice if the community showed a little humility
While I have no claim to represent the community, I fully intend to use this episode to explain to management why Open Source is much more secure than Microsoft Windows. I've seen nothing in this to cause any humility in the Open Source Community. It took Microsoft three days after the outbreak of Code Red before a search of Microsoft.com for Code Red returned any results. I haven't seen any response yet about the Chinese posting of something like 7 exploits.
Damn it, think of all the vulnerable Knoppix CD's out there... with no way to upgrade the kernel!
Now you have a large choice, and while people wont immediately replace an OS they might over time ..... (also since over 50% of microsofts Os's is made up by older OS's (ME and 98 IIRC) this invalidates your point.)
For instance back in 99 or 2000 you could buy a p3 server (which would still be plenty usable today) from just about anyone, however not to many major manufacturors were offering linux as an OS (and arguably nobody wanted to run it) so you buy the server, bring it to the NOC or datacentre and wham bam your off and running. two years or so later the market goes into the toilet and spending is reduced, you now have to upgrade some of the stuff on the server (such as the webserver or email server) do you:
a. lock yourself into microsofts new and improved licensing (that will have you bent over a barrell if your not a huge company)
b. overpay for a product that offers little incentive to use compared to the cheaper competition.
c. go with a cheaper alternative that is making large headway in the market.
A TON of CIO's (something to the ilk of 73% were planning on using linux more extensivly in the fiscal 2003 year) and admins are choosing C, because of A and B and even if the percentage is 10% that is still a very large chunk of people that would generate a 20% shift. (minus 10 from ms add 10 to linux et all)
"Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe." --Albert Einstein
See KB825750
null sig
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?
This whole exploit comes with a nice timing. I mean, Debian is the only real open source platform (ok, there are some others, but not on so many platforms). Microsoft announces that they are going to compare windows against linux, updating patches, number of vunerabilities...
Dunno call me paranoid.
The site where: "I'm right, as long as you ignore the things that prove me wrong", became a valid method of debate.
ohhh ohhh, me too.
I have a nforce2 board. It's an Epox. I had a shed load of problems to begin with, but after a few BIOS upgrades and installing >=2.4.21 everything has been fine.
My only problem now is the nvnet module doesn't set up the LAN for WOL. Damnit!!
"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."
Also probably the entire US power grid:
http://www.theinquirer.net/?article=12875
Interesting to look at this exploit and see how it works. Does it apply to the 2.6 kernels as well though ?
Of course is all started with password sniffing.
The issue - clear text passwds bad.
of course it could have been an inside job...ie someone with valid access to the box who then sniffed a passwd to disguise what was going on..
updates for 7.3,8.0,9.0 & Fedora are all available now from RH and some mirrors.
I am, and always will be, an idiot. Karma: Coma (mostly effected by
OK. For anyone else who, like me, still has gaps in their knowledge and is trying to fill them, what exactly is an "oops", and where is a good site explaining about these - and other ways of monitoring your system?
(Hey, just 'cos I'm clueless at some things doesn't mean I don't want to remedy the situation =^.^=)
Tiggs
Tiggs
"120 chars should be enough for everyone..."
nobody knew it was exploitable.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Bronaugh!
:-)
Are you calling me a liar or just trolling me, as usual?
+++ATHZ 99:5:80
Also probably the entire US power grid:
;-)
http://www.theinquirer.net/?article=12875
Wasn't this in the end attributed to an Unix machine failing?
"Slashdot article"
I'm not a rarity. I'm a relic. A dinosaur with an appreciation for the methods which genuinely work in the interest of doing things right. I actually stick with low level flowcharting. You know, the kind with the boxes, circles, and parallelograms where each figure on the flowchart translates into about 1-2 lines of real code.
:-)
Thank you for the comments. I feel honored.
+++ATHZ 99:5:80
Local holes must be considered almost as bad as remote: I almost got rooted earlier this year because the cracker got user 'nobody' access via a buggy PHP script, then used the buggy PHP script to launch a local root exploit. Fortunately, I'd implemented a workaround against the local root exploit.
Oolite: Elite-like game. For Mac, Linux and Windows
Kind of takes like a worm. A Blaster worm.
My beliefs do not require that you agree with them.
Wow. I'm glad you can eliminate hardware just because it has a brand on it.
That brand must mean that motherboards don't have overheating problems, RAM doesn't ever fault or fail, hard drives don't crash when the system is jarred.
Yep, you have proven that a bluescreen could not be caused by hardware - as it is branded hardware.
Woah, a helpful AC. Thanks for the heads up, though I really have no issue with NVidia's binary drivers. (Unlike certain Free software zealots) Sure, GPL'd drivers would be nice, but well-working propriatary drivers are fine too.
Any word on the parties behind the attack?
The perp is a blackhat discovering vulnerabilities and using them in the wild without any published exploits by security researchers.
The reason I mention it is that there's frequently a chorus of folks around here saying that full disclosure is a bad idea because that's the only way people get exploits. This incident again proves that theory incorrect.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Isn't that a contradiction?
Windows NT/2K/XP uses a microkernel, which basically *is* a bunch of subsystems. Linux is a macrokernel which is more like a big pile of bits.
Actually, Apache runs 67.41% of all domains, versus IIS running 23.46% of them. I remember one Netcraft Survey where they said more than 50% of machines are running IIS/Windows. What you can gather from this is far more Apache machines run one or more domains than IIS machines do.
I used up all my sick days, so I'm calling in dead.
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
I agree that it does, but generally only in situations just like you described - faulty hardware. It's that with XP they've generally moved to more graceful ways of dealing with problems. These days, a BSOD is about equivalent to a kernel panic under Linux.
Well, to be pedantic, it was always equivalent to a kernel panic under Linux. Perhaps now it happens less often and is therefore roughly as rare, but IMHO kernel panics in Linux not caused by hardware are much more rare than Windows BSODs not caused by hardware unless you are doing driver development, in which case both OSs shoudl crash roughly as often ;).
Maybe you could explain where in my post I said it was a "secure system"?
I was explaining why they use the terminology they do, and why it makes sense. I don't think a properly configured OpenBSD is any more secure than a properly configured Linux.
Please take the time to comprehend posts before you waste the time responding to a point that wasn't made.
UML, but that is a long stretch from code flowcharting.
So, what's the difference between a UML activity diagram and a flowchart? Almost none at all, modulo minor tweaks to the symbology. Statechart diagrams are almost unchanged from traditional state transition diagrams (perhaps they didn't like the unfortunate acronym STD). Class diagrams are pretty much ERDs (entity relationship diagrams) from DB design. The only thing missing is DFDs (data flow diagrams) although collaboration diagrams are pretty close.
UML didn't replace flowcharting, it just formalized the notation and enlarged it to handle OO concepts.
Mind, I don't think I ever actually used my IBM Standard Flowchart Template (a plastic stencil of flowchart symbols), only ever sketched flowcharts on a whiteboard as part of process analysis. (And no, beyond ancient textbook examples, I don't think anybody ever flowcharted code down to the statement level.)
-- Alastair
Well sir, I guess I have to retract the part of my earlier comment where I said I didn't think anybody had ever flowcharted code down to the statement level.
Let me guess, you are/were either a COBOL and/or IBM Assembler programmer. (I don't think I've ever seen anyone else go to that level of detail -- hmm, maybe Fortran IV programmers too.)
(As for me, if I had to do a formal flowchart, I'd write the code first and run it through a flowchart generating program. But all that was decades ago. Not counting UML activity diagrams, of course.)
-- Alastair
Nah, I'm just saying you either have a very good sense of humour or a strong tendency to use hyperbole :P
A patch for 2.4.21 can be found here:
http://www.vanheusden.com/Linux/lsecpatch.diff.gz
www.vanheusden.com - home of Multitail, HTTPing, CoffeeSaint, EntropyBroker, rsstail, bsod, listener, nagcon, nagi
MP3 files are played by executing Windows Media Player, which is obviously signed, since it comes from Microsoft!
Tired of free iPod sigs? Subscribe to my blacklist
That's more like four or five problems. :)
I'm not sure what "management" you are worried about. Tape the key phrase to the front of the machine. (We're talking about a server, locked in a room.)
To revoke the key, you can reinstall the entire OS with a different key, or simply replace the key in the existing kernel if you're confident. The former should be pretty standard practice in a breach scenario. Note also that "if the key is cracked" should be an unlikely scenario. Crackers are like water, flowing downhill towards the easiest attacks. Cracking a good encryption key is a pretty significant enterprise.
In the scheme we're talking about, the administrator signs the code. This can either be done by a compiler, or by an installer program, depending on your paranoia level. This is not much more complex than apt-get or rpm asking for a root password before proceeding.
If the source is compromised, then the key buys you nothing. However, realize that this is no worse than before, so it's not a "problem" of this scheme, but simply an attack it does not protect against. (This doesn't protect against somebody prying open the door to your server room, either.)
It's rediculously complicated to use public key encryption even with only server software. [...] They're banking on the fact it's confusing, possibly impossible, to manage all those keys and signatures
How so? The compiler (on a different, preferably disconnected machine) would ask you for the private key when you build the software. It is no more complex than managing licensed software with keys tied to a machine, which most administrators already do competently. Maybe there's a misunderstanding. I'm talking about one key (to match the public key installed in the kernel) per machine, which should be no more trouble than a notebook locked in a room.
My relatively new Toshiba laptop with XP blue screens about once or twice a week. It started with the November update of Asheron's Call.
It is amazing what you can accomplish if you do not care who gets the credit. -- Harry Truman
It would also mean that its removal from the kernel was already under way.
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.
I'm not 100% sure on this one since i'm using redhat and mandrake (and gentoo) for all my machines, however:
binary packages are normally signed by the development team. if the binary packages were changed at all, the packages won't match the signature and the installer should refuse to install them (or at the very least, warn about the signatures) so really the debian distribution should still be safe to use (again, this is assuming that their installer checks signatures. which, considering debian's scrutiny, i'd be surprised if it didn't)
Please keep in my that my ADHD keeps me a little scatter brained and I sometimes can't focus long enough to
I think you're mistaken; the vocal "anti M$" trolls have ALWAYS looked pretty stupid. These are the same people who think that Linus Torvalds should devise some grand strategy to "crush micro$oft". They flock to Linux(and no other OS) because they want to be anything but microsoft, oblivious to the people who are using it because it's the right tool for the job(which sometimes it is, obviously). Unlike the people using nearly any other non-microsoft OS, they seem to focus their attention directly at an operating system they aren't even using, of all things(either Linux or Windows, it depends on whether said anti-m$ zealot is an idiot or a hypocrite), instead of just using what they want to use. Perhaps that's why so many would swear to god that Linux is user freindly in all ways; instead of actually looking for something that's easy to use(the correct way to find something user freindly, by the way), they just look for something that isn't MS, and apply whatever qualities they want to it's description, without regard to reality.
Actually, it kind of reminds me of an article on adequecy.org -- how to write satire for geeks.
Anyway, while these people were busy trying to play some sort of strange alpha male act with the largest software company in the world, Microsoft got the picture and started making OSes people could actually use. Go figure. Capitalism is funny that way.
It's been a long time.
Funny! Almost as funny as the look on the face of the average Windows user when you show them menuconfig and explain to them that that is a GUI. ;-)
quiquid id est, timeo puellas et oscula dantes.
Windows local bugs are sad...
#include<stdio.h>
int main(void){
while(1){
printf("Die!!!\t\b\b\b\b\b\b");
}
return 0;
}
Compile away, and have a nice kernel panic.
What a moron! No wonder you were too much of a pussy to post with your account!
Manipulate the moderator system! Mod someone as "overrated" today.
This code tests for the vulnerability, rebooting your system if it is found. Requires nasm greater than v0.98.36, tested with nasm 0.98.38.
I have to say, I'm impressed they found the cause. That's a very neat piece of investigation, I'd say. Great job!
Let's see... the Debian project had three boxes compromised. The MO of the attacker seems to be to install a rootkit on the compromised machine and look for passwords caught by the keylogger. Then using the captured username and password, log into another machine, escalate privileges using his exploit, install another rootkit, lather, rinse & repeat.
To me this means one thing. The stolen Debian developer account was almost certainly stolen because the developer logged into a Debian.org server from a box that was already compromised. And who knows how many other boxes has this individual or group compromised already?
In fact, anyone offering public shell access (eg SourceForge) on Linux could have been easily affected by this vulnerablity. And anyone who logged into another Linux box from a compromised machine runs the risk of having their machine rootkitted already.
Admittedly this is nowhere near as bad as a remotely exploitable hole, but it's still bad. Once you're local on the machine (whether using some kind of remote login or an exploit in userland software), on Unix systems* your next step is privilege escalation, which is what this exploit lets you do. This makes a relatively minor intrusion (if permissions are used sensibly) into a full-blown one that requires re-installing the machine.
No software is perfect and these things do happen. But pointing out how Windows had worse holes in the past doesn't really help anyone who got 0w|\|3d this way. OTOH the Debian announcement was brilliant, they did a great job of explaining what happened and how. The only omission was made by the kernel guys for not recognising that this bug would allow privilege escalation, otherwise the fix would have been made available a lot sooner. Unfortunately for everyone, the person who did recognise the opportiunity chose to use it for his own purposes rather than reporting it.
So to sum it up: the ball was dropped, machines were compromised and saying that Windows is worse (apart from stating the obvious ;-)) doesn't help anyone. So let's try not to take it personally and get defensive (I know, it's hard thing for me as well), patch your boxes and move on.
* And any operating system that properly restrict the accounts used to run services. Privilege escalation attacks exist for Windows as well, but they're needed less often since whatever you're compromising is likely to run with 'LocalSystem' privileges anyway.
I signed up for a
Yup, I've seen the exchanges between someone else @helsinki.fi and a certain Dutch professor about this topic! (And even though I'm a linux user, I think AST was right, monolithic kernels are a relic from the dark ages.)
The microkernel architecture protects the individual components from each other, but unfortunately doesn't protect the system from the component that is in charge of it. Damage limitation, but not damage prevention.
Christ, your record collection _ROCKS_! Did you see Wigwam and Tasavallin Presidentti in the Savoy Theatre last night?
YAW
Your head of state is a corrupt weasel, I hope you're happy.
It might not be easy to tell from just the kernel version but there are obviously errata security warnings on relevant web pages and/or mailing lists (which everyone should at least check if in doubt), that mention the specific package version/release with backported fix.
Thanks. The list is hopelessly outdated and I'm too lazy to bring it up to date anymore.
Did you see Wigwam and Tasavallin Presidentti in the Savoy Theatre last night?
No I wasn't at that gig, I attend too few concerts for my own good (whatever that means).