Hands-on testing of the new Linux virus

Thanks to one of our readers, NewsForge has obtained a copy of the widely reported Windows/Linux cross-platform “proof of concept” virus. News reports thus far on the code have contradicted themselves: some reported the virus can replicate itself on both Windows and Linux, others saying it has a viral nature only on Windows. Testing by both NewsForge staff and Hans-Werner Hilse may reveal why the confusion.Our tests shows the code’s viral nature is sometimes — but not always — effective on both platforms, depending on the kernel being used. Of course, it’s impossible for us to test every version of the kernel out there, but thus far, it looks like those prior to version 2.6.16 are susceptible, and at least some of those after that release are not. Here’s how we tested at NewsForge.

Our first test was run on an AMD64 box with a fresh install/update of Ubuntu Dapper Flight 5 386 with the 2.16.15-20-386 kernel, with the WINE and GHex — a binary viewer/editor — packages also installed. After unzipping the viral package (clt.zip) into an empty directory, we tested CLT.EXE by executing it under WINE in a subdirectory containing only a small executable and linkable format (ELF) file, called hello, written in assembler, that we created for the test. We ran CLT.EXE, and a small window popped up saying that the “dropper” — as the code calls itself — had executed successfully.

When we examined the hello ELF file with GHex, however, it showed no signs of contagion — not even the lines of text which were supposedly installed in lieu of the virus itself when run on Linux. We soon learned that the reason hello remained uninfected in the first test was that the hello executable file is too small, not because the viral code could not replicate on Linux. Another NewsForge staffer testing CLT.EXE under VMWare found that it did infect larger ELF files.

Next, we copied the programs more, date, and ls from /bin into the test directory. When we ran CLT.EXE again, all three of those ELFs were infected. Each was 4,096 bytes larger than it had been before the test. But did those 4,096 additional bytes actually contain the viral code? Would the ELF files still execute? Those questions became the basis for our next test scenario.

Instead of running CLT.EXE under WINE, we repeated the tests in a different directory, using uninfected copies of the same target programs, and then executing an infected version of ls in that directory. The only difference we could detect was that the pop-up window no longer appeared: more, ls, and date were all infected and hello remained untouched.

Meanwhile, on the other side the Atlantic

Hans-Werner Hilse has been digging deeper into the viral code than we did. Hilse described his initial testing as follows:

2.4.26 running in qemu (I took an ISO of Damn Small Linux) — qemu
simulates a Pentium II — I was also able to see the infection taking
place.

I found a difference for the program flow when I compared the systrace
from the 2.6 kernels mentioned above (2.6.16.2 and 2.6.15.4). Indeed
the mmapping fails on the newer kernel:

(command is “strace -viqo strace.log ./echo x”, “echo” is /bin/echo but
an infected version, another copy of echo — not infected — is waiting
as “E” to be infected).

—>2.6.15.4:
[08047416] readdir(3, {d_ino=10933298, d_name=””}) = 1
[0804742d] stat(“E”, {st_dev=makedev(3, 7), st_ino=10933298, st_mode=S_IFREG|0755, st_nlink=1, st_uid=1000, st_gid=100, st_blksize=4096, st_blocks=40, st_size=16600, st_atime=2006/04/14-21:31:09, st_mtime=2006/04/14-21:31:09, st_ctime=2006/04/14-21:31:09}) = 0
[0804744d] open(“E”, O_RDWR) = 4
[08047463] ftruncate(4, 24792) = 0
[0804747e] old_mmap(NULL, 28672, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0xb7fca000
[0804749c] munmap(0xb7fca000, 24792) = 0
[080474a7] ftruncate(4, 20696) = 0
—>2.6.16.2:
[08047416] readdir(3, {d_ino=722045, d_name=””}) = 1
[0804742d] stat(“E”, {st_dev=makedev(3, 1), st_ino=722045, st_mode=S_IFREG|0755, st_nlink=1, st_uid=1000, st_gid=100, st_blksize=4096, st_blocks=48, st_size=20696, st_atime=2006/04/14-21:31:09, st_mtime=2006/04/14-21:31:31, st_ctime=2006/04/14-21:35:16}) = 0
[0804744d] open(“E”, O_RDWR) = 4
[08047463] ftruncate(4, 28888) = 0
[0804747e] old_mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_SHARED, 1, 0) = -1 ENODEV (No such device)
[080474a7] ftruncate(4, 20696) = 0

so obviously the mmap in 0804747e fails on the newer kernel version.
What makes me wonder now is that the syscall is named “old_mmap”.
Sounds like a deprecated interface…

Hilse continues to test, looking to discover why the virus works on some kernels and not on others. The last we’ve heard from him was this:

My earlier suggestion seems to become true. The ebx register
is actually reset to “1” after the “ftruncate” call. Compare the both
register dumps to see this. Before the ftruncate-syscall, ebx is 7.
After that call, when interrupted at breakpoint #3, it is 1.

I don’t know for sure if this is normal behaviour. But many
sources on the Web seem to suggest that for Linux syscalls the
registers except eax should stay unmodified (i.e. get reset when
returning from kernel into userspace). This is what many assembler
examples seem to suggest. So I really think the kernel might be wrong here.

We sent an email to Linus Torvalds to let him know about our testing. He replied:

That said, it sounds like it’s a regular program that just happens to work
on both Windows and Linux, and that happens to do things that are
perfectly OK per se (i.e. writing to files that are owned by the user). So
it’s interesting just because of the “works on both Linux and Windows”
angle, not because of any viral nature.

A post we sent to the Linux Kernel Mailing List offering the “proof of concept” code to any kernel hackers interested to trying to figure out why it works on some versions of the kernel but not on others has been ignored. Obviously, the people concerned about the inner workings of the kernel are not as concerned about this threat as those selling anti-virus software.

Based on our examination of the code, Linux users need to be aware of two things. First, given the right permissions, a virus can replicate itself on Linux. This, however, has never been in doubt — it remains to be seen whether malware authors can create a virus that can spread as easily on Linux as viruses on Windows. Second, this “proof of concept” is an excellent example of why running as root is a very bad idea.