Wine being targeted for adware
http://philosecurity.org/2009/01/12/interview-with-an-adware-author In an interesting interview, former adware author Matt Knox mentions that he was able to run his adware client on Wine: S: In your professional opinion, how can people avoid adware? M: Um, run UNIX. S: [ laughs] M: We did actually get the ad client working under Wine on Linux. S: That seems like a bit of a stretch! M: That was a pretty limited market, I'd say.
On Wed, Jan 14, 2009 at 05:08:50PM +1100, Jeff Zaroyko wrote:
http://philosecurity.org/2009/01/12/interview-with-an-adware-author
In an interesting interview, former adware author Matt Knox mentions that he was able to run his adware client on Wine:
S: In your professional opinion, how can people avoid adware? M: Um, run UNIX.
S: [ laughs] M: We did actually get the ad client working under Wine on Linux.
S: That seems like a bit of a stretch! M: That was a pretty limited market, I'd say.
Well, I spotted some Adware in my Wine lately that got installed with some "free" Web Media Player. It seems to fail to inject stuff into the Windows Firefox 3 though. Ciao, Marcus
Jeff Zaroyko wrote:
http://philosecurity.org/2009/01/12/interview-with-an-adware-author
In an interesting interview, former adware author Matt Knox mentions that he was able to run his adware client on Wine:
S: In your professional opinion, how can people avoid adware? M: Um, run UNIX.
S: [ laughs] M: We did actually get the ad client working under Wine on Linux.
S: That seems like a bit of a stretch! M: That was a pretty limited market, I'd say.
As long as the facilities exist for keeping an entire wine bottle isolated from other bottles (and ~/) I don't see this being a major issue. Unlike disinfecting on a Windows box, which might not completely eradicate the software, with Wine `rm -rf ~/.wine` and its gone :) The cool thing is that you can identify exactly what the junkware does with KDiff3 if it runs at all. -Nick
As long as the facilities exist for keeping an entire wine bottle isolated from other bottles (and ~/) I don't see this being a major issue. They don't.
Even if you don't have a drive link pointing out of a bottle, a Windows app running in Wine can still call Linux syscalls(int 0x80). This is possible/needed because Windows apps run as a regular Linux process that links in Linux libraries which perform linux syscalls. So any Windows malware can break out of the Wine "sandbox"(which isn't a sandbox really) by simply using linux syscalls.
Stefan Dösinger wrote:
As long as the facilities exist for keeping an entire wine bottle isolated from other bottles (and ~/) I don't see this being a major issue. They don't.
Even if you don't have a drive link pointing out of a bottle, a Windows app running in Wine can still call Linux syscalls(int 0x80). This is possible/needed because Windows apps run as a regular Linux process that links in Linux libraries which perform linux syscalls.
So any Windows malware can break out of the Wine "sandbox"(which isn't a sandbox really) by simply using linux syscalls.
On more recent distros (FC9/10) SELinux is enabled by default. Rolling a policy specifically for an untrusted bottle would severely limit the damage it could do. It could restrict all unnecessary read/write/execute access outside of the ~/.wine folder for wineserver and the program. I see your point though, since none of the aforementioned security precautions are commonplace or specifically targeted to wine.
I see your point though, since none of the aforementioned security precautions are commonplace or specifically targeted to wine. A security measure targetted to wine would be a wrong thing IMO.
Either its designed for Windows, then it will protect the Windows apps in Wine the same way. With exceptions of course, anything based on rootkits will probably never work, and it may not know how to deal with int 0x80 syscalls Or design it for a generic Linux app, and it will protect the Windows app running in Wine(Windows app + Wine == regular Linux process). Again there are possible exceptions. Some security measures can break Windows apps, for example Adress space randomization can break apps. What works only in a very limited fashion is using Windows apps to protect the Linux system. You can use a virus scanner to do a manual check over your drives, but scan-file-on-open features will likely fail.
Stefan Dösinger wrote:
I see your point though, since none of the aforementioned security precautions are commonplace or specifically targeted to wine. A security measure targetted to wine would be a wrong thing IMO.
Either its designed for Windows, then it will protect the Windows apps in Wine the same way. With exceptions of course, anything based on rootkits will probably never work, and it may not know how to deal with int 0x80 syscalls
Or design it for a generic Linux app, and it will protect the Windows app running in Wine(Windows app + Wine == regular Linux process). Again there are possible exceptions. Some security measures can break Windows apps, for example Adress space randomization can break apps.
What works only in a very limited fashion is using Windows apps to protect the Linux system. You can use a virus scanner to do a manual check over your drives, but scan-file-on-open features will likely fail.
I've run into problems with ASR when using wine with some apps. If you do a: `setarch $(uname -p) RL wine ./app` and disable ASR then it works again. Any security policy would have to be targeted as if the program was written for Linux. It wouldn't be much more involved than limiting what it can see and do just like policies that target httpd and other services.
Stefan Dösinger wrote:
What works only in a very limited fashion is using Windows apps to protect the Linux system. You can use a virus scanner to do a manual check over your drives, but scan-file-on-open features will likely fail.
There has been demand to implement a ClamAV powered on-access file scan within Wine. That should fill that niche nicely, and also more elegantly since we don't have to run a Wine process to check the Wine system. This has the added benefit of making it harder to compromise the virus checker itself, especially since that can then reside outside the user's home folder. In a very real way, we could handle Windows security better than Windows. Thanks, Scott Ritchie
2009/1/15 Scott Ritchie <scott(a)open-vote.org>:
There has been demand to implement a ClamAV powered on-access file scan within Wine. That should fill that niche nicely, and also more elegantly since we don't have to run a Wine process to check the Wine system. This has the added benefit of making it harder to compromise the virus checker itself, especially since that can then reside outside the user's home folder. In a very real way, we could handle Windows security better than Windows.
Yes. Attempting to run the virus checker on the system you're protecting is basically *insane*. An outboard checker on a different OS is a ridiculously better idea. The main problem with restricting access outside an app's WINEPREFIX is not that it's a bad idea (it's a great idea), but that it could lead to undue overconfidence on the part of users and an expectation that this will actually meaningfully increase security. - d.
What works only in a very limited fashion is using Windows apps to protect the Linux system. You can use a virus scanner to do a manual check over your drives, but scan-file-on-open features will likely fail.
There has been demand to implement a ClamAV powered on-access file scan within Wine. That should fill that niche nicely, and also more elegantly since we don't have to run a Wine process to check the Wine system. This has the added benefit of making it harder to compromise the virus checker itself, especially since that can then reside outside the user's home folder. In a very real way, we could handle Windows security better than Windows. Actually, what I wanted to say is that you can't use a Windows virus scanner in Wine and expect it to cry wolf when you open e.g. a bad document with the Linux version of OpenOffice.
2009/1/14 Jeff Zaroyko <jeffzaroyko(a)gmail.com>:
http://philosecurity.org/2009/01/12/interview-with-an-adware-author
In an interesting interview, former adware author Matt Knox mentions that he was able to run his adware client on Wine:
S: In your professional opinion, how can people avoid adware? M: Um, run UNIX.
S: [ laughs] M: We did actually get the ad client working under Wine on Linux.
S: That seems like a bit of a stretch! M: That was a pretty limited market, I'd say.
"Some adware can work under Wine on Linux" does NOT mean that Wine is being targeted in any way. Note that viruses also work in Wine. Not much you can do about it, since they are valid Win32 applications ...
2009/1/14 Jeff Zaroyko <jeffzaroyko(a)gmail.com>:
http://philosecurity.org/2009/01/12/interview-with-an-adware-author In an interesting interview, former adware author Matt Knox mentions that he was able to run his adware client on Wine:
The amazing thing about that interview was how jaw-droppingly insecure Windows actually is, inherently and incurably. I hope Wine doesn't emulate some of those wackie characteristics too well. - d.
2009/1/14 Ben Klein <shacklein(a)gmail.com>:
2009/1/14 David Gerard <dgerard(a)gmail.com>:
2009/1/14 Jeff Zaroyko <jeffzaroyko(a)gmail.com>:
http://philosecurity.org/2009/01/12/interview-with-an-adware-author In an interesting interview, former adware author Matt Knox mentions that he was able to run his adware client on Wine:
The amazing thing about that interview was how jaw-droppingly insecure Windows actually is, inherently and incurably.
I hope Wine doesn't emulate some of those wackie characteristics too well.
Technically, it has to for legitimate apps to work. I'm sure there's some malware that doesn't work in Wine, but there's probably a large subset of that will work some day.
Oops, missed "Reply to all"
participants (7)
-
Ben Klein -
David Gerard -
Jeff Zaroyko -
Marcus Meissner -
Nicholas LaRoche -
Scott Ritchie -
Stefan Dösinger