On Wednesday 18 February 2009, Ben Klein wrote: > 2009/2/18 Martin Hinner <mar...@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.do...@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