Slashdot Mirror
Linux Virus Alert
marcjw writes: "I don't see many of these (Linux virus alerts). In fact none in the six months or so since I've switched from MS. Maybe that's why this story from newsbytes caught my eye. At any rate, I'm not sure if this poses much of a threat to the general Linux community but it's always best to be forewarned."
Any smart Linux user doesn't usually run their computer with root permissions. Until Windows XP, all consumer versions of Windows (9X, Me) ran all users at an eqivalent to root level, enabling viruses to wreak havok at any time. Macs were the same way before OS X, but virus writers still targeted Windows because of the large installed base.
What services use this EGP protocol?
I'm assuming that if my box doesn't run anything that uses this, then it's not vulnerable to exploitation.
Sig (appended to the end of comments you post, 120 chars)
Part of it's because of the relative lack of security on a Windows box; only NT and XP had/have an administrator level where regular users aren't allowed to do things.
95/98 let anyone run just about anything as default. And XP actually does this too... Default accounts are set up as administrator without passwords.
And while you can run everything from an administrator account (got root?) under Linux, the type of person who installs Linux generally knows better than to do so.
It's because of the limited access that most accounts have that makes viruses difficult to write under Linux.
As to why malicious coders concentrate on MS, it's because it's easy. The coders at MS keep making the same mistakes over and over again. Look at the UPNP exploits.
I like you, Stuart. You're not like everyone else, here, at Slashdot.
So, I see defense of Linux already. But why not place some blame on those who made this security hole? One of the major things Linux has going for it is it's lack of security flaws, and lack of virii.
But it's not a hole. It's the "beauty of unix security". You can do what you want as root, and pay the consequencecs, or run as non-privilidged luser, and only screw up your own files. What **I'm** waiting for, is the *nix virus that binds to non-privilidged ports, infects normal lusers(by looking for permissive permissions in pathed directories)
The previous has been a secret message to my comrades.
Naturally, the average user skill and level of vigilence by Linux developers helps too. But I think the basic design plays a big part in the lack of viruses.
Ita erat quando hic adveni.
hmmm.. social engineering anyone?
./runme
./runme
localhost:~$ tar zxf some-random-binary-0.0.1.tar.gz
localhost:~$ cd some-random-binary-0.0.1
localhost:some-random-binary-0.0.1$
This program must be run as root.
localhost:some-random-binary-0.0.1$ su
Password:
localhost:some-random-binary-0.0.1#
Sucka!
Another point.. when was the last time you actually checked the code of something you've compiled? lets say instead of some-random-binary, it's some-random-young-sourceforge-app. Jeez, get off your fucking high horse.
Well, the primary reason would be the lack of any viruses to scan for.
It is only "crazy" to not scan for viruses from the mindset that viruses are out there. It isn't crazy to take a road trip in a car that doesn't have a spare innertube if the car uses tubeless tires.
It is also important to note that this article is not about a virus. It is about a trojan. There isn't really any way to do an automated check for unknown trojans on any platform, since the scanner can't know what the program is supposed to do in to first place to figure out if it is doing something else as well.
The question with Linux binaries is are they what they claim to be. That question is generally answered with an MD5 sum from a trusted source. This renders the case of unknown trojans moot.
-Peter
and so on. Symantec/Norton also has a Linux/UNIX binary which is certainly bundled with the network-wide thing, I don't know if it's available separately. The trouble with all of these things is that although they are Linux applications, they detect Windows virii - they use the same signature files as the versions on other platforms do. This means they're very good for running on file/e-mail servers to protect the poor Windows machines behind them (which is what they're intended for) but they probably won't stop the subject of this post, for example. Basically, yes, they exist and work well but make sure you know what you're hoping for them to do...
Perhaps I'm wrong on this, but this is a trojan, not a virus. Viruses reproduce and spread automatically, and from the article's description, this does not. Requiring users to run something at each point that it infects is NOT a virus, it is merely a trojan horse.
Mozilla's a nice operating system, but it needs a better browser.
RPMs or other packages that are downloaded from more or less untrusted locations without encryption signatures might very well run a few evil scripts during the installation process (which, of course, is done as root).
To be really sure, one should always install new programs in a chrooted jail; the software should be installed in a totally new branch of the filesystem tree and the installation process should not be able to read of write to other parts the filesystem.
A lot of smart alecs here are making light of this, but let's face it, the smart thing is to give time to any virus at all. Tell me you've never, ever, left yourself in as root by mistake. OK, now tell me no-one else has. 'Nuff said.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Section "InputDevice"
Identifier "Mouse1"
Driver "mouse"
Option "Protocol" "PS/2"
Option "Device" "/dev/mouse"
Option "Emulate3Buttons"
Option "Emulate3Timeout" "100"
EndSection
Section "InputDevice"
Identifier "Mouse2"
Driver "mouse"
Option "Protocol" "IMPS/2"
Option "Device" "/dev/input/mice"
Option "SendCoreEvents"
Option "ZAxisMapping" "4 5"
EndSection
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
OK, I'm really sick and tired of those people who say "Oh, I run binaries as root, so you do too."
/usr/local?
/usr/local is writable by my staff. My staff consists of... me. So, I have root, my desktop login and staff. Just install stuff on /usr/local, as staff. Voila. Staff can't touch my $HOME or any of the system binaries. So any malicious script (at install time aka make install) is pretty much contained in... /usr/local.
/usr/local/bin as my desktop login. I loose my stuff. You can argue that this is just as bad, but my system is still not compromised.
Have you every thought of
./configure --prefix=/usr/local?
My
Let's say I run a infected binary in
This isn't rocket science, guys.
From someone who apparently doesn't use Windows. Outlook has never automatically run an executable attachment. It used to give you an option to execute it, but only after a prompt stating that such files may be harmful. Currently it completely blocks the attachments, and the only way to get to them is to either have the sender rename it, compress it, or change a registry setting, where Outlook will pop a big red dialog. Automatically open executables? Please, research before you type.
He was probably mailed a copy, same as I was. (That is, someone said "here's a virus I found", not that they were trying to hide it.)
I've got no way to tell that the person who sent me my copy isn't the author, but I've also got no reason to suspect he is.
In any case, this is why I can't speak to whether the virus is "in the wild". But, it exists, and it works, so I passed the info along.
Personally, I always run make -n install just to see what it is going to do (it's easier than opening the file if I think it already has the right paths set). It's one of those extra steps that Just Make Sense (TM), like prepending 'echo' when you rm with -r or with wildcards as root. You'll be glad you did when you look at the output, slap your forehead, and breath a sigh of relief. =)
Extra sidenote: if you're compiling a program that uses GNU autoconf (etc.) to configure the makefile, you might be interested in the --prefix= option (where you can tell most sane programs to install somewhere other than the default). I always install to a test directory in my home directory before going system-wide (so I can, say, test a new version of an app).
You run `make install` as root.
You run 'd[e]select' as root.
You run 'apt' as root.
You run 'rpm' as root.
When was the last time you actually checked the code of that app you took off of Freshmeat?
UNIX application programmers are _still_ using the occasional gets(3) call in setuid root programs, more than a decade later,
I doubt it - name one! Try compiling this on your machine:
#include <stdio.h>
int main (int argv, char *argc[]) {
char str[100];
gets(str);
}
I don't think there's ANY recent libc that will not print a harsh warning, and some will even refuse to compile it. I know this because I recently had to go through an ancient program for creating phylogenetic trees, and change dozens of gets to fgets to get it to run on FreeBSD.
Use checkinstall. Run it instead of make install and it'll create a rpm | tgz | deb package to install (and uninstall, if need be) with your packaging system.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
# Save this as Makefile and try "make -n install" /sbin/shutdown now)
# with GNU Make.
#
# This runs even with -n, and doesn't print first.
foo:=$(shell
#
# This too runs with -n, but is displayed.
# (I use a semicolon in case slashdot loses tabs.)
install:; +echo this runs too
Is that so? I believe you are mistaken - SDL is only a wrapper library which calls out to existing methods of doing graphics (among other things).
One such method is Xlib, and I don't want to run an X server. Another is the Linux kernel framebuffer, and I'm not so interested in taking the performance hit of running in frame buffer mode (why do you think I use a text console in the first place - mostly for speed). A third is aalib, and I don't want to run Doom in ASCII art (slashdot reports about Quake notwithstanding). Which leaves me running SDL applications in ... svgalib mode. Which requries root.
"Xlib is really old.. Gtk+ is the way now."
The two statements are equivalent.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README