Cross-platform virus?

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Eric Dunbar wrote:
> On 19/04/06, tomski <ulist at gs1.ubuntuforums.org> wrote:
>> Hi there,
>> i'm just as confused as you if not more ???
>>
>> i thought to get infected you would need to install/compile it yourself
>>
>> am i wrong????
> 
> It's not a virus (not even proof of concept... that's a fiction
> created by a Russian anti-virus manufacturer trying to drum up
> business).
> 

Bull shit.  The virus when executed will locate a PE or ELF executable
in the same directory and inject itself into the executable, increasing
the target's size by 4096 bytes.  Yes, it works.  Yes, it fails to
spread due to a bug in 2.6.16.  Yes, Linus fixed it.

> As for someone else's query about whether or not it's truly
> cross-platform because it ran under WINE (I think it was WINE)... it
> does run natively under both Windows and GNU/Linux and is able to
> modify an executable from the one OS that'll run under the other...
> 

All viruses are written to compile to a source executable which either
A) is infected (difficult), or B) is capable of constructing the
infection from itself, and has a copy of the infection logic in its run
path.  (B) is slightly more interesting because the virus author can
prevent payloads from being dropped and direct which executables to
infect, without propagating the code to allow for this.

That being said, the source executable used here does not run on Windows
and Linux; nor do infected files.  The propagated virus, however,
modifies itself to match the target executable's system.  This means
that PE executables have Windows-friendly code injected with any
Linux-specific modifications stored as data; while ELF executables have
Linux-friendly code injected with any Windows specific code stored as data.

> ...but...
> 
> ... it can only modify existing executables if the host user has
> permission to write to the target executables.

Irrelavent, we'll get into this later.  It can also only propagate if
the host user has access to the files; windows can't touch EXT2, Linux
can't touch NTFS.

> 
> It's basically an old piece of code that is capable of running under
> two OSes (that's the cool part) -- its viral properties are a subject
> of debate. You've got the anti-virus company on the one side spreading
> PR and FUD (this is real FUD) and you've got people who know the
> difference between their ass and a hole in the ground saying the
> opposite.
> 

This is not FUD.  The AV company is trying to gain some attention, but
this is not total FUD.

Remember above that I said you can't infect Linux from Windows or
vice-versa because they can't write to eachothers' partitions.  These
cross-platform infection methods are quite useless due to this.

The interesting part comes when you create a WORM.  Worms spread by
holes in things like IIS or Apache, buffer overflows, default passwords,
etc.  On the attack, they can determine the target system and now modify
themselves to run on it.  This makes a worm cross-infecting, but very
fragile.

A peer-to-peer worm would be more dangerous with this.  Modular
programming design can give the following sections:

[Core]--[Infection Logic]--[Windows code]
      |                  |-[Linux code]
      |                  |-[MacOSX code]
      |-[Spread Logic]--[Attack Code selector]--[IIS vu#111000]
      |                                       |-[IIS vu#111001]
      |                                       |-[Apache vu#203011]
      |                                       |-[Linux-tcp vu#211993]
      |-[Comm Logic]--[Encryption]
                    |-[Command Logic]--[Code sharing]--[Binary modules]
                                     |               |-[Source code]
                                     |-[Build host]--[Code compilation]

Such a worm would be able to use encrypted pipes using randomly
generated asymmetric keys and symmetric session keys.  This would be
breakable by man-in-the-middle; however, it would be sufficient enough
to allow for injecting code into a worm and letting it propagate the
worm network, without it ever being possible to determine where the code
originated from, giving the attacker some level of secrecy of identity.

This means an attacker could create such a worm, with the ability to
spread cross-platform, that could be extended by injecting
cross-platform source-code blobs of attack code modules into it (i.e.
plug-ins!).  Meanwhile the worm is capable of spreading cross-platform
to Windows, Linux, and MacOSX; can be extended via injected code blobs
to infect other systems on other architectures; and in general is a mess.

In virus form--that being, the worm once infecting a host proceeds to
inject itself into existing executables and libraries--the worm could be
designed to also encrypt itself and its code blobs, using randomized
encryption keys and interchangable cipher code.  This would allow its
signature to change--  all but the cipher code is stored encrypted, and
so the signature is tied 100% to the cipher code.  This technique won't
work on Systems with either PaX or with SELinux policies preventing
mprotect(...PROT_EXEC) from !PROT_EXEC,
mprotect(...PROT_WRITE|PROT_EXEC), or any creation of
PROT_WRITE|PROT_EXEC memory, as the virus/worm could not decipher its
code in memory and would thus have to generate the code on-disk and
mmap() it in, triggering an on-access anti-virus check or SELinux policy
denying access.

The worm could easily simply propagate and stay resident; CodeRed and
SQLSlammer used this venue and faired very well.  As soon as the machine
is off, the worm is gone; but as the worm can be made to grow and adapt
and "learn new vulnerabilities" (by injecting code for them into an
existing copy and letting it share it with the others), it would be able
to re-infect hosts as soon as a new known vulnerability crops up that
they haven't patched.  This gives the worm extreme staying power.

To prevent its sudden neutering-- injection of code that kills the
worm-- the worm could simply spawn a copy of itself and run it with the
new code.  The current copy will eventually die out as vulnerabilites
are closed; the new will spread.  Neutering code like "EXIT NOW" or
"while(1){sleep(999999);}" will not spread.  Worms encountering more
code will collaborate with all copies on the system to spawn new copies
with all of the discovered code.  Code EJECTS to remove dead vulns could
work the process in reverse to maintain a shrunken worm size; or code
could be timered to die on a set time period or over a long time of not
being used.

This is all hypothetical of course.  The idea of a worm that can obscure
itself; slowly be taught to infect new types of systems; slowly learn
new vulns and automatically kill dead ones; and adapt new code to new
architectures automatically is ridiculous, is it not?

> One link recently posted here points to a bug-fix provided by Linus
> which updated the Linux kernel to allow the code to run. Because it's
> so old it relies on some 'register' behaviours that -- although not
> formally supported -- were broken in newer kernels. It only actually
> ran on old kernels (until this update -- isn't it nice that Linus is
> providing bug fixes for virus writers :-).
> 
> Eric.
> 

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond

    We will enslave their women, eat their children and rape their
    cattle!
                                     -- Evil alien overlord from Blasto

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBREfC2Qs1xW0HCTEFAQJCoQ//VVm8T+szbynNYVsoA9LZiC8G9Y3nEw10
/p6pId8ilUy1pfd9ym1D4nJXG/8oq1f3ylM8QgBa4TKobXQ7Vdqwff1E4cEo/VkB
hEULSeUqGigw6m+E+1Ly7ARxd1FCoWL4LIGJmHYkHiNsuExfNNaNbQ3Ui8sye9aD
MHb16cKf4HviyJX7dFKLseZ9BFXzktHsbSdbrcW40is0RstR2MNWhOCQE9kS+DGz
85hgOYvKKjEaC5Uj9l/7Ilut9LHTf++o4i4j1YRdQaCtADFv6WVN71nVl8W5afyK
p38obr22OcprTBRcxBh2N3JdNAYxcIwnx+ijZ3L3oX5OArtzY6fhEaEdwZ3E8xCO
JaGiLHArsOE9eGEFtmgsup4AfmQFnry2+qBnk+ObreEz70UveXW10+lKjsbFGCDL
pm4IWDD3GTqmlAtAe/3tam+J6vcYwwJZ/0z8j6uHxG9VEyActQmoz0Z70C1g0vwz
G4I9TqpjrkRv8Z1Agv4QC8FETKny9ERxfV3YWqTt3QiMXTfF1Tw3yIaE+6Nb2rWJ
qOA8xiUKJRqcSxN84aRKm7Tj482eYfN59KOfaGoTZ+duDZ4kp68JKhYmrQVagAG9
m7o22aF60kTN32Ban36C5yW4t57ix0/RgGgnI0BCKp27J5gn/mKa2FkyAPfEEvgR
1RfYy2wv8vE=
=fBCQ
-----END PGP SIGNATURE-----