Now Linux Can Get Viruses, Via Wine

fsufitch writes "Wine has advanced enough to make Linux not immune to Windows viruses. However, just like many Wine applications, it takes a bit of effort to get the program off the ground. Also, just like some Windows programs running via Wine, not all features may work — in this case, the crippling of the system, immunity to the task manager, identity theft, etc."

Comments

Experiments

[Aquaseafoam]

I work as a sysadmin at a company making a slow switchover to Linux, and I've experimented with this a bit. You can greatly, greatly limit the damage any virus can cause through wine by unmapping it's Z drive from the wine configuration menu. By default, wine maps / to Z. I can see why they did this, (wine can only run applications within a mapped drive) but it likely needs to be undone across the board. The best alternative would be to create a unhidden wine folder in the user's home directory and map that in wine. If Z is left mapped to /, then a windows virus can run rampant all throughout your system.

Re:Experiments

[TheRaven64]

A virus that is Linux-aware can escape from a WINE sandbox like this very easily. WINE handles Windows library calls, but it can not intercept system calls. If you put a Linux system call number into eax and issue interrupt 80h then you get a Linux system call, irrespective of whether it's a programme running with WINE or a native Linux program. Remember, WINE is not an emulator, it is just a loader and a set of libraries. It doesn't provide any sandboxing. WINE even provides a mechanism for allowing programs to detect if they are running under WINE, so if you can persuade a Linux user to run a program under WINE (or infect another program running under WINE) then you can do anything that the user can do. Unless, of course, you combine WINE with SELinux or some other real sandboxing mechanism.

Re:marketshare

[TheRaven64]

Except on BSD systems, which only accept arguments before other arguments. This prevents someone from putting a file called -rf in a directory, so when you run rm * the -rf won't be expanded and treated as an argument. If your system doesn't do this, then you should get into the habit of putting -- after the arguments and before the options.

Re:marketshare

[Bert64]

The idea of multiuser is to protect one user from another... You wouldn't be able to keylog other users at least, and sending spam is something that identd on unix was supposed to deal with, tho the prevalence of single user systems has rendered ident pretty much totally worthless.

Also, nonroot malware is much easier to remove, especially on unix, because there are only a very limited number of places it can hide on the filesystem, it can't do neat tricks like mark areas of the disk corrupt and hide there, it can't hide in system directories amongst the thousands of other files already there, it cant modify the kernel to hide itself... It will show up in the process list when running, whereas with admin privileges it can easily hide itself to the point that you need to boot from clean media.

Re:Windows virus needs help to limp onto WINE

[Korin43]

His command is actually even more complicated than it needs to be (deleting wine and reinstalling it). rm -rf ~/.wine && wine will delete the wine folder and rebuild it without the added pointlessness of reinstalling the binaries.

Re:Linux's distribution model helps though

[reub2000]

su when invoked by an admin doesn't need the users password. And sudo can be used to run su without ever getting the root password, so he's basically gotten a root shell only using the password associated with his own loggin. Of course, 'sudo -s' is a much simpler way to get a root shell.