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..."
Actually, the Morris Internet Worm struck way, way back in 1988...
Real Daleks don't climb stairs - they level the building.
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?
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);
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.
You can always give a non-super user rights to install stuff into /usr/local for example. Hint: Groups.
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.
-- "--," ?
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. /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...)
Of course that still won't stop someone from the staff group to install virused-software into
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.
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