Win32/Linux Cross-Platform Virus 582
An Anonymous Coward writes "Symantec reports on the first virus to infect both ELF and PE binaries on Linux and Win32. "The first Win32/Linux cross-infector, {Win32,Linux}/Peelf, uses two separate routines to carry out the infection on PE and ELF files. This variant of Simile shares a substantial amount of code between the two infection functions, such as the polymorphic/metamorphic engines, the only platform-specific parts being the directory traversal code and the API usage.""
Re:This is great news! (Score:4, Interesting)
Nice to run on Linux mailservers.
Re:One more reason... (Score:4, Interesting)
On my debian system:
# find / -perm +u+s -uid 0 -ls | wc -l
27
And on Redhat 7.3, 42
Hundreds. Bah. Please do some research before you spread FUD.
Chroot apps are heavilly scrutinized for security issues. Many even give up root permission after doing whatever they absolutely need to do as root.
You would have to find a chroot app that had an exploitable buffer overflow problem to begin with. The virus would have to specifically be written to exploit that particular bug in that particular application. This is non-trivial.
From Semantec: "So far Symantec has not received any submissions of this virus from customers."
So how did symantec find the virus? Who had it? How did they get it? How is it spreading?
Many people have suspected for YEARS that virus companies manufacture viruses to sell their products. I'm not saying they are, but this smells VERY fishy. I'd like some answers.
Cool! (Score:5, Interesting)
Re:why i love my mac (Score:1, Interesting)
Re:One more reason... (Score:3, Interesting)
Why, because you are likely to get the virus through a bug. If the virus can find an exploit to penetrate your system, then it's very likely that it will also find the local root exploit to do anything it wants.
You really need to close all the entrances.
Prophecy: look 6 months forward and we will see virus/worm that, after entering your system, scans it for weak points, after that it downloads the suitable root-exploit just for your box, runs it and starts the bugparty. At that point, lazy maintainers will get a cure for their laziness.
Re:Cool! (Score:1, Interesting)
Slim Binaries not only solve the problem of compatibility between different architectures, they also allow to fine-tune the object code towards the specific processor and operating system version that it will run on.
The basic idea is that the compiler stops after generating the parse tree and encodes that. Code generation is then done at runtime. It's similar to the idea of using bytecode for a virtual machine, except that unlike bytecode, parse trees are much easier to inspect as they are of a symantically higher level. This means that it's a heck of a lot easier to recognize (for example) IPsec crypto processing and offload it to the integrated IPsec hardware on your ethernet card without the programmer having to do the footwork involved in detecting the device. Slim Binaries also make code verification a reasonable prospect, which is very exciting when you consider the security implications of applets and agents.
Freakin' Genius (Score:3, Interesting)
Kinda scary. Next time you're in linux, it connects to somewhere over the net telling the author another box has been rooted and voila, he ownz you.
Kinda a good reason not to run Windows in dual boot mode I'd say.
There's some preemptive stuff you can do with this though.. Have a kernel module (possibly compiled in) that does checksums all your major binaries before booting and warns you when they've changed. Of course, the virus has total kernel access too, so this may not be effective if the author planned for it.
Re:Do antivirus companies write viruses? No. (Score:4, Interesting)
And by the way, you can infect ls and ps and df. Every now and then, I log in as root, to do some maintenance-type thing, or install something. And while I'm root, if I run a virus-infected program, then the virus has root privilege, and can infect ls and ps and df and anything else it wants to.
This does ignore one trait of Unix users, though. Normally I run as a regular user, and I don't have permissions to write to system files or root's personal files. All I can infect is my own, and all my executables live below my home directory. When I su to root, I have things set so that the path automatically gets reset to the system defaults which do not include anything under home directories and most emphatically doesn't include the current directory. This means that, as root, I can't run any of the files that might have been infected by a virus run by any regular user without jumping through some hoops first (which I'm unlikely to do exactly because they're dangerous and unneccesary). This vastly reduces the ability of a virus to spread across the system. Not eliminates, I can always do something stupid, but vastly reduces.
A virus can destroy my data files, but that's why backups were invented. At worst I lose a day or so's worth of work, whatever was done since the last backup. The new generation may be different, but the older of us view backups as somewhere between a religion and an obsession. This should be system-independent, really, and in this day of cheap CD burners and large-capacity Zip and Orb drives and such there's no excuse.
so can we modify this virus to do some good? (Score:3, Interesting)
99.997% of all virii spread because the virus writers know that the end users are dumb as a box of rocks... hell, how many times have we had email spread viruses, and people STILL open attachments without a thought.. (Wow dave's sending me nude pictures of his wife again!)
the only way to stop virus attacks are to either kill all the users (I wish!) or disable the dangerous options in the software they are using.
only then will we stop the virus problems.
Re:Do antivirus companies write viruses? No. (Score:5, Interesting)
Now, my question: I still don't understand how a virus could get widespread on Unix. A worm, yes, but not a virus (eg, the Morris worm and that redhat LPRng thing a year ago).
I agree that if I run an infected executable as root, I'm screwed. I'll even say that if I run an infected executable under my regular user account, I'm equally screwed because it's my data that's important, not the system (as you point out).
However - here's the big difference - how am I going to end up running an untrusted executable? My mail client never runs untrusted code. In fact, if someone sends me an elf binary, I have to go through several steps in order to save it, chmod it and then run it from a terminal. In Windows, you can get emailed a .exe attachment and you can double-click on it and it runs. This is where that lack of distinction between programs and data actually helps: nothing is a program until I decide it's a program. When I download a perl script using netscape, it will first get 0644 permissions, so it won't be run via the hash-bang mechanism even if it's in my PATH and it won't be run by "perl script.pl" unless I type that into a terminal. If I do something stupid, like making netscape's handler for .pl files "perl %s", then, yes, I'm in trouble, but the default configuration for netscape does not use any interpreters.
Basically, my point is that I have to go through some trouble to intentionally run a program downloaded off the 'net, which makes it unlikely that I'm going to run a program unintentionally. As for stuff that I run intentionally, those would be source tarballs and the occasional binary executable install program. For these, I just have to trust the origin of the program, but I get to make that decision.
About the only thing I'm worried about virus-wise is that if some closed-source program like Realplayer has a method for embedding executable code in audio streams, or if AOL's instant messenger program embeds commands in its chat protocol. This is the confusing of data and programs that you mention. Another example would be emacs's auto-execution features. For example, you can add this to the bottom of a file:
This tells emacs, vi and vim to use four-space tabs. Now, emacs is a full programming language, so if one could embed arbitrary lisp forms in this manner, this would cause problems. However, the emacs people already thought of this, so it won't work.Another thing that scares me is auto-update features for binaries. For example, if Realplayer includes an auto-update feature, someone can hijack their servers so my next auto-update contains some new "features." But then, if someone hijacks Real's domain, they can just change the binaries I initially downloaded intentionally. I don't see how a virus scanner could help me out here as anyone who does this is likely to write their own little program in C or assembly.
I'm not familiar with the state-of-the-art in virus scanners, but I can think of a number of ways to obfuscate arguments to system calls, or even encrypt the code that performs system calls and do it all without using libc - I don't see how any heuristic approach could differentiate a rootkit from an media player installation program. Perhaps a virus scanner could detect the popular rootkits and the popular encryption methodologies, but how it's going to tell that the "unlink" system call called with "getenv(HOME) /.realpayer" is OK but "unlink getenv(HOME)" is not OK? Especially if the arguments are not static strings but are put togehter in some fashion and the code for the system calls is taken from .data, copied to the stack, unencrypted using an algorithm I just made up and then jumped to (and the target for the jump is calculated using some complex formula, so you can't search for simple jumps into stack). And this is all off the top of my head - I've never even written any code that runs on the stack. My point is that if someone is knowledgeable enough to break into a server I trust, they may be knowledgeable enough to write a program that bypasses a virus scanner. And if this is the case, why even mess with a virus which attaches itself to other programs instead of installing a rootkit and sending off my IP somewhere? It doesn't make much sense to me.
There are plenty of unix security issues that keep me on my toes, but these involve buffer overflows in network daemons and setuid programs, poorly written perl cgis and php scripts, firewall scripts, tripwire configurations, etc. - I'm not worried about viruses. The distribution mechanisms that virus kiddies use just don't exist in Linux.
Firemen, too. (Score:4, Interesting)
True story: My dentist, when I was a kid, would give out lollipops. Pure sugar, artificially-colored, decay-inducing lollipops. Swear to God.
Also: More than one fire department has been caught setting fires to put out. (It's especially prevalant among volunteer fire departments, which are often composed of people who enjoy playing with fires.)