Slashdot Mirror


Win32/Linux Cross-Platform Virus

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.""

2 of 497 comments (clear)

  1. Cool! by mindstrm · · Score: 5, Interesting

    Now.. if only we could get those same brilliant minds working on a compiler that produces a single executable that works on both platforms, and shares as much code as possible.

  2. Re:Do antivirus companies write viruses? No. by Permission+Denied · · Score: 5, Interesting
    First, I'd like to thank you for creating a slashdot account and contributing to the discussion.

    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:

    # vi:ts=4
    # vim:et:ts=4
    # Emacs:
    # tab-width:4
    # indent-tabs-mode:nil
    # End:
    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.