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.
(A: Microsoft)
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.
As the BOFH would say.
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.
Now that Linux is coming up as winner and MS shows like the Wizard of Oz it is, we should investigate not who, but how did such exploit materialize.
Seriously, if such an exploit has been shown in September and was not patched, some unknown opportunist who hates Linux/Unix (and, yes, there are such beasts) could have time to code the exploit.
Now, not seriously, who could profit from this?
Who discovered the flaw?
Andrew Morton.
Who maintains Kernel 2.6?
Andrew Morton.
Who would profit more if Linux Kernel 2.4 was declared unsafe and Torvalds recommended immediate upgrade to 2.6?
Now Mr. Morton, where were you on Wednesday 19th November (2003), at approximately 5pm GMT?
You sure understand this question is merely rhetoric...I rest my case. Guards, take Mr. Morton to the dungeons. Children, don't look now... this won't be pretty.
Couldn't find it in ChangeLog-2.4.23 :-/
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!!!!
And they call Windows unsecure. How does crow taste, Slashdot?
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.
It seems that someone found the bug in -preN or -rcN kernel and used it before the final kernel found its way to be published.
This is the important lesson for kernel maintainers - if you found the security bug, publish the new kernel ASAP.
I work for Mandrake, and yes, we have checked our machines.
--jackson.
What the fuck? This gets modded as funny, yet #7602986 gets modded as a troll?
What moronic mods.
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.
Gentoo's machines are being upgraded over the next hour. However, Gentoo forbids password logins for ssh (pk only), so they're less vulnerable to password stealing anyway.
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.
on the night the Debian machine was 0wn3d?
I present to you Exhibit A:
This problem was found in September by Andrew Morton, but unfortunately that was too late for the 2.4.22 kernel release.
Yes, Mr. Morton - you admit you had the means - now I will prove to the jury that your also had THE MOTIVE!
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)
while debian security alerts are sent by cryptographically signed email, mandrake reassuringly posts AC on /.
riiight...
Great..... there goes my uptime.....
If I have to reboot more than once per year, I'm switching to Windows.
Nothing is perfectly secure.
When's the last time Windows had an outright kernel exploit? At least their stuff is in the subsystems.
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?
It's ok because it's the kernel that's been exploited; not Debian. wtf? what's Debian without the Linux kernel? and what's Debian without GNU software? This is like saying that it's apache that was exploited and not Debian so it's ok. That attitude, loose it. An admin is supposed to patch his shit and not blame it on the developer.
I get flamed and downmodded constantly for my sig. And yet, here is an outright exploit in the very Linux kernel itself. Open Source software is as insecure as any other large application. How does that crow taste?
I know I risk being downmodded, but I just had to say this. I get flamed for being a so-called "Microsoft shill" constantly for pointing out the obvious--operating systems are as secure as their admins/makers. It's not a religion, folks. Here is a buffer overflow exploit embedded right in the kernel.
It'd be nice if the community showed a little humility, but, of course, next week this story will be forgotten and drowned out by repeat dupes of some "Microsoft hole" that is really an executable attachment ran by Outlook users or something.
Nothing ever changes, but at least it's good to know the developer community around Linux knows their software is not perfect and constantly strives to make it better. It's all those vocal "anti-M$" trolls that have called Slashdot (and OsNews.com) their home who look pretty stupid right now.
"Sufferin' succotash."
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."
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."
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.
Let's get in the Wayback Machine to 1998, shall we?
I haven't seen Clippy in over seven years in any subsequent release of Office. I can say the same about BSODs as well, but the "jokes" never cease.
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
No, I work for Mandrake and I hacked Debian's servers.
I thought the stable Debian distro was based on a 2.2 kernel. No wonder I switched to Gentoo...
How reassuring. So if I root a gentoo-developer's machine, I automagically get into the gentoo-servers without sniffing passwords. I just use his ssh-keys instead.
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.
You're obviously trolling, but I've gotta point out the obvious: According to the advisory this hole was discovered in September. The last vulnerable kernel was released in August. So no, they were not aware of a potential root exploit at the time they released the kernel.
Good luck!
Use ISO 8601 dates [YYYY-MM-DD]
Right. So instead of stealing the password the intruder has to take the extraordinary step of stealing the key. And you've got an even worse problem in the general case when dealing with keys, because you have a hard time enforcing things like password expiration (just how long can someone use that stolen key to get into your system?)
What I find intriguing is that those fine folks at Debian have come this far at detecting the exploit and tracking down the who's and why's (with the who's still being left undecided for the public, anyway).
Honestly, if I were smart enough to sniff a password, I'd also be smart enough not to let anyone know I've sniffed. Still, the folks at Debian were able to blame the unpriviledged account part on a sniffed password. Now how do you gain evidence for something like that?
Likewise, if I'd be smart enough to gain local root access by flipping the kernel, I would also be smart enough to ditch the binary with which I did that. Nevertheless, though after a thorough research, the Debian team has found the binary and managed to understand its potentials.
But still, what intrigues me the most is that they have found out that they were hijacked in the first place. Now I have a rock solid system for that at home, which is an 8 Mb RAM Sparc Classic, which starts to trash so hard at the least of activity, that I would well be alarmed if someone else than me was using that machine for whatever purposes. But as I may assume that those Debian machines weren't that low-end, how could you ever expect to know when you have been exploited?
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
passphrases, you idiot...
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.
The Church-bell peals slowly.
Linux is kernel-level exploitable.
Windows is not.
QED.
If you think this is a flame, then you need to have your head examined; this is nothing more than the truth.
ScottKin
I don't give a rat's behind about "karma" here or anywhere else. Don't like what I have to say here? Deal with it!
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?
I could not find mention on Redhat's bugzilla. Do they know about it?
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.
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.
What kind of accident left you without fingers?
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
Most crypto applications could also be applied to DRM. So what? DRM is only DRM when it's actually implemented.
(BTW, Windows 2000 and up already allows the administrator to restrict anything except signed binaries. Yet my MP3 files still play.)
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
It does add a struct into a linked list, but it only records the value of the "len" field, but doesn't do anything in particular with it. It's not kernel memory management corruption... it's a address-space mapping mistake.
It calls functions that unlock various pages, but it looks like that in the wrap-around case, it panics BEFORE it gets a chance to do this. I'm wondereing what values of len are required to do something interesting, therefore.
Holy shit man, I mean everyone enjoys a good wank especially to the fine pr0n on the internet these days but in a big open room with hundreds of other people walking around!? WTF!
Did he thinking he was folling anyone with that sleeping bag?! LOLOLOLOL...
Well I guess he's sexually liberated, I mean he obviously has no shame if you can jack off in a room full of people with no embarresment..
Wow man that was crazy, seriously, jacking of in a XXX theatre is frowned upon nevermind some big ass LAN party. What a nut.
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.
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
sue 'em, I say...
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 ----
ur ghey.
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
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]#
Buffer overflow exploits have been a problem since at least the sendmail worm of 1987. Is it too much to ask that programmers check boundaries for Every Effen Buffer They Declare, already?
What'll it take? Public ridicule of the programmer? GCC refusing to compile unsafe code? What?
This is beyond lame. It is willful, ignorant and destructive stupidity.
I herewith suggest that any programmer who writes a 'hello world' program with an unchecked buffer be summarily drummed out of the service.
Grumpliy Yours,
AC
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
And she does all her hacking in a bikini. With high heels. yeah.....
only pussies need GUIs.
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
DO NOT REPLY TO OCG--HE IS A KNOWN TROLL AND YOU ARE BEING BAITED!
as aslk fja waerjufa a, erdf apewr lkjaf ad fk jwer wepo i roer lskjw da slk fje eirw rjoiwelkrj seoiwej eirwdk emweo
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
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.
... hey, it's just as good as Windows!
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
With digital signatures is of course managing the signatures! If a key is cracked you have no way to revoke it cleanly. Then you have to deal with who signs the code. Do you compile and sign your own code? How do you know the source is good? If someone else signs it who are they? Do you trust that person?
It's rediculously complicated to use public key encryption even with only server software. This is Microsoft's solution to everything by the way. They're banking on the fact it's confusing, possibly impossible, to manage all those keys and signatures so they hope everyone will just use Microsoft signed code and screw all the rest. Enter Palladium.
Damn it, think of all the vulnerable Knoppix CD's out there... with no way to upgrade the kernel!
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.
Most distros backport security fixes (this one's just a one-line fix), so it won't be that easy to tell.
local users!
Pete
ftp.gnu.org 0wned, undetected for four months
FSF writes good software but they suck at system administration.
Ah, another linux kernel exploit. I sure am glad Im running Windows!
Manipulate the moderator system! Mod someone as "overrated" today.
Didnt you know Micro$oft has an IP on implementing bugs!?! ...
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.
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..
And this approach differs to the equivalent of Linux in what way?
"If you're running ftpd, you're going to be keeping it updated and tracking bugs for it."
How does this make BSD any more secure? Do you mean it is more secure since the one using the 'standard install' is going to keep it updated and continuously tracks bugs in it? I mean what the heck? The system itself is NOT any more secure when you have to avenge for insecurities whether and especially when you have to do it on 'the other' system as well..
And if you need patches it means the system is not secure. There is no such thing as a "secure system"!
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
RMS doesn't believe in system administration. He also doesn't believe in having useful documentation, or properly maintained mailing lists, or people to manage and provide answers on those mailing lists.
Sign up to a couple of GNU mailing lists (If you can find them!) and see your daily spam intake double!
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
Kind of takes like a worm. A Blaster worm.
My beliefs do not require that you agree with them.
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)
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.
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
It would also mean that its removal from the kernel was already under way.
YES! YES! I'm seeing it:
Kernel Size: 18Mb.
Performance compared with C: 2%
Hardware supported: 0%
Are you a fscking retard?
"RUNTIME SAFETY?" - Who is going to provide your fscking runtime safety if you're writing a program that runs on BARE hardware? The interrupt controller? Or the UART chip?
Do you have any fsckin idea wtf you are talking about? Runtime safety, my ass.
C# is a JIT language. It is not machine specific - kernels are cause the FSCKING HAVE TO BE. Whats going to interpret a "kernel", another non-C# kernel?
Moron. You're probably one of those idiots who writes a qbasic program like
PRINT "WLECOME TO SUCKIX"
PRINT "-----------------"
and thinks he is writing an OS. ROFLMAO.
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!
Thank you Captain Obvious!!!!!!!!!!
root@grinch:~$ uptime
17:45:22 up 3411 days, 1:22, 30 users, load average: 1.89, 2.11, 2.23
Yes, it needs more processor. It's running on a 386 for goodness sake. Running Linux kernel 1.1.37.
Linux teh good.
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
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.