Winux: Postmortem

To find out how much damage the w32.winux "virus" can do to a properly managed system, Exocore tested it after downloading the executable and source code from the author's web site.

The following is a report by Exocore researchers Shanker Balan (shanu@exocore.com) and Kuruvilla "Sony" Philip (sonz@exocore.com):

The winux binary (winux.exe) was run within Windows ME from a directory on a VFAT filesystem. This directory also had the 'ls' binary that we had transferred from a Linux system. 'ls' is used to list directories under Linux or Unix, an approximate (but more powerful analog to the "dir" command under DOS/Windows).

On running Winux.exe, it patched all executable files in the current directory with its payload including the 'ls' linux binary. Both Windows PE and linux ELF executables showed a change of date and timestamps. However, only the linux binary showed an increase in size.

It did not traverse directories, though this would have been a trivial function to implement and can be expected to appear in future mutations of the virus.

To verify the infection, we copyied the altered 'ls' binary to a non-root user's home directory under linux We renamed it to 'ls-infect' to distinguish it from normal 'ls', and then ran the standard string-extraction utility 'strings' on it.

$ strings ls-infected | grep -i winux
[Win32/Linux.Winux] multi-platform virus by Benny/29A

This clearly identifies that winux.exe had modified 'ls'. The size of the file had also increased.

$ /bin/ls -l /bin/ls
-rwxr-xr-x    1 root     root        43740 Aug 25  2000 /bin/ls

$ /bin/ls -l ls-infect 
-rwxr-xr-x    1 user1    user1       46524 Mar 28 16:37 ls-infect

The infected file had increased by 2784 bytes.

The next step was to see what 'ls-infect' could do. We put two copies of the original 'ls' command into the user's homedirectory - ls1 and ls2. One was chowned to the user's uid and the second one had the same perms as /bin/ls, i.e. it was owned by root.

$ /bin/ls -l ls*
-rwxr-xr-x    1 user1   user1      46524 Mar 28 16:37 ls-infect
-rwxr-xr-x    1 root    root       43740 Mar 28 16:33 ls1
-rwxr-xr-x    1 user1   user1      43740 Mar 28 16:37 ls2

And then we ran ./ls-infect, and then checked the sizes again:

$ /bin/ls -l ls*
-rwxr-xr-x    1 user1   user1      46524 Mar 28 16:37 ls-infect
-rwxr-xr-x    1 root    root       43740 Mar 28 16:33 ls1
-rwxr-xr-x    1 user1   user1      46524 Mar 28 16:37 ls2

'ls2' which was owned by user1 has been modified while 'ls1' owned by root remained untouched, as winux was unable to write to the file.

Then we did a strace on 'ls-infect' which seems to reveal that 'ls-infect' tries to patch every file in the current directory only with the payload. It also tried to patch non-executable files and those which are not owned by 'user1'. Unix permissions however denied write attemps to the files not owned by 'user1', as is expected under Linux (or any UNix).

strace log when 'ls-infect' tries to patch a text file .bash_history:

readdir(4, {d_ino=65493, d_name="bash_history"}, 0) = 1
open(".bash_history", O_RDWR)           = 5
lseek(5, 0, SEEK_END)                   = 469
old_mmap(NULL, 469, PROT_READ|PROT_WRITE, MAP_SHARED, 5, 0) = 0x4014a000
munmap(0xbffff7e5, 1075093504)          = -1 EINVAL (Invalid argument)
close(5)                                = 0

strace log when 'ls-infect' tries to patch a file not owned by the user (ls1 is owned by root:

readdir(4, {d_ino=65498, d_name="s1"}, 0) = 1
open("ls1", O_RDWR)                     = -1 EACCES (Permission denied)

Conclusion:

The "virus" winux is more of a trojan, and in effect does nothing very different from what a cracker would have attempted to do (replace executables or execution code) over the past 30 years. Normal Linux/Unix permissions prevented it from causing any damage other than to the current user's files. As such users are not expected to own any executable binaries, this is hardly cause to worry.

However, if this "virus" is run by a root user in a directory containing system executables (for example the /bin or /usr/bin directories), considerable damage would be caused. Again, this is in line with the way Linux/Unix works. "root" users by definition would not allow the introduction of a strange binary, and normal security systems like tripwire would have caught a "changed" binary like this and alerted the system administrator.

Bottomline:

Winux is not something one needs to worry about on its own. In order to be effective, it would have to find a way to compromise the basic security of the system - not a trivial task on a decently managed system.

In combination with a badly administered system (with security holes), it could be cause to worry. However, the concept of a system being broken into is far more of an issue than what is done after the system is broken into.