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..."
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.
Windows has had batch file viruses for ages.
Actually, if I were inclined to mod you down, it would be because the first Unix worm came out in 1988.
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.
Actually, the Morris Internet Worm struck way, way back in 1988...
Real Daleks don't climb stairs - they level the building.
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.
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.
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 :-)
I suppose Ramen doesn't count.
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.
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!
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.
/tmp doing stuff, and maybe write to a users .bashrc (or equiv) so the virus get to run when ever the user logs in.
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
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
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!
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
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?
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.
FoundNews.com - get paid to blog.,
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? /usr/bin
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
delete free(system.gc);
Not many people know this but:
/dev/tcp/localhost/22
cat
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.
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
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.
Is it just me, or was this story posted mainly to spread the use of the word malware?
Amazing magic tricks
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.
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.
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.
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
Remember the fiasco we had a while back about "What's your shell prompt" and people posted (and used) malware prompts?
/.ers, because Slashdot itself has been a method of spread for malware in the past.
Linux shell malware isn't a surprise for us
-twb
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.
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.