Wine & viruses

Mihai Donțu mihai.dontu at gmail.com
Wed Feb 18 08:12:49 CST 2009


On Wednesday 18 February 2009, Ben Klein wrote:
> 2009/2/18 Martin Hinner <martin at hinner.info>:
> > Hi,
> >
> >  I will start one more hot discussion. Sorry if it was discussed
> > earlier, I am not regular reader of this mailing-list. I tried to
> > search google, found several discussions, but no real result:
>
> It won't be very hot.
>
> > http://www.linux.com/feature/42031
> > http://www.vnunet.com/vnunet/news/2116150/linux-experts-wine-virus
> > https://bugs.launchpad.net/ubuntu/+source/wine/+bug/256880
> > wine-devel mailing list google results
> >
> >  The problem is that some (almost all?) distributions simply execute
> > .exe file when you click on it. I was amazed when testing JTAGTest on
> > Linux! This is in my opinion quite big issue as ordinary users do not
> > have problem clicking on "New folder.exe" on their flashdisk etc.
>
> Well, that's a problem with, at most, the distribution or, at least,
> the user being silly.
>
> > It's good that wine is so compatible that it runs even viruses, but I
> > think there should be some (optional) protection. The biggest
> > problem seem to be removable media, in many distributions mounted
> > under /mnt or /media.
>
> Removable media can be mounted literally anywhere. It'd be easier to
> find it with HAL, but it's not something suitable for Wine.
>
> > Please think about this twice before writing "problem is in
> > Microsoft not in Wine", "it's not a bug but feature", etc. It's too
> > childish IMO.
>
> Hmmm, let me think about this ... and again ... it's not a bug, it's a
> feature. There is no 100% fool-proof way to determine whether the user
> is about to run some malware or some legitimate application.
>
> > - What about creating a configurable list of directories, where wine
> > would first ask if you really want to execute the program? It would be
> > up to distribution what is set-up by default.
>
> Again, this is not something suitable for Wine. Perhaps getting the
> distributions to mount removable media with the noexec option would
> help. Of course, this wouldn't help if .exe files were associated with
> Wine via the file managers, but maybe you think that should stop too.
>
> > - It's long time I have been interested in viruses, but I think that
> > 90% of most common virus infected/trojan .exe files can be pretty
> > easily identified. Almost every modern virus is trying to connect to
> > the internet either by opening socket or using few standard DLL
> > functions.
>
> Gee, this sounds like ever other networking application. Why? Because
> GOOD viruses, trojans, worms etc. are suitably disguised as genuine
> applications.
>
> > What about adding some checks to Wine that would check the
> > calling function code sample against some small database to see if
> > this is a virus and ask user? Or adding some "API" functions to allow
> > someone to write such program?
>
> What you're suggesting is to include a standard virus scanner in Wine.
> Not going to happen. Use clamav instead. It's opensource and has
> *nix-native versionns.
>
> > I have done quite a lot of work with PE loading and code
> > modification and I think it could be moved to level when it works
> > without crashing anything.
> >
> > I understand, that none of this is system solution. But are
> > anti-viruses system solution? They solve real world problem.
>
> "System solution"? Anti-viruses are the only reasonable solution.
> History of computer science has shown us that the harder you try to
> prevent something the harder other people try to do it. Anti-virus
> programs mitigate some of that, detecting known viruses and
> quarantining or deleting them. They're not perfect, but they're a lot
> better than what other options we have.
>
> A new version of Wine is released every 2 weeks. This is too long to
> keep a virus database up-to-date, and a lot of people don't upgrade as
> soon as the release comes out any way.
>
> > Regarding API I have mentioned above I mean some hookdll() function
> > that would re-direct GetProcAddress() or PE loader for defined
> > functions, i.e.:
> > http://www.codeguru.com/cpp/w-p/dll/hooking/article.php/c3639
> > http://www.codeguru.com/cpp/w-p/dll/hooking/article.php/c127
>
> Redirecting GetProcAddress() sounds more like a security hazard than a
> security feature to me. Someone correct me if I'm wrong.
>
> > Obviously this would have to be global for wine (libwine.so?), not as
> > a PE exported API function. Pre-loaded "antivirus" would be able to
> > hook Winsock functions + some other important stuff and then check if
> > the binary code is not on the list.
>
> Check out clamav and other *nix-native virus scanners. They're much
> more suited for this task than adding a full-blown virus scanner to
> Wine as standard. Who wants to maintain something like that?
>
> 2009/2/18 Mihai Donțu <mihai.dontu at gmail.com>:
> > I think that soon there will no longer be a need to hack wine in order to
> > prevent the spread of malware. There is already work in progress on an
> > API (a derivative of dazuko) that will allow for antivirus scanners to
> > intercept all filesystem accesses and scan for, well, viruses. It seems
> > to me that this is the right way to go.
>
> Wine is not intended to prevent the spread of malware. It is assumed
> that the user is careful and sensible, just like it is assumed on
> Windows.

While I'm with you on this one, this method is yet to be widely adopted among 
desktop users.

> What you mention here sounds like an API to allow 
> Windows-based virus scanners to run, checking both loaded apps and
> scanning hardisk when changes occur, but there are better solutions
> for virus scanning on *nix systems. I keep mentioning clamav.

I was actually referring to this[1], which started when people wanted to 
create malware-free file servers in an easy way (without proprietary modules, 
Samba VFS, proxies etc.) and as with all good designs, it covers a wide range 
of cases, including this one.

[1] http://marc.info/?l=linux-kernel&m=123368869002717&w=2

-- 
Mihai Donțu



More information about the wine-devel mailing list