February 2009 - Wine-Devel - list.winehq.org

Re: Malware on Wine review

by Gert van den Berg

Not sure exactly where in the thread this fits in, but here goes.... On Tue, Feb 24, 2009 at 1:58 AM, Zachary Goldberg <zgold(a)bluesata.com> wrote: > 2009/2/23 Dan Kegel <dank(a)kegel.com>: >> Ben Klein <shacklein(a)gmail.com> wrote: >>>> http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows… >>>> >>>> "Do not set the file association for Windows executables with Wine. >>>> This would enable running Windows executables in Wine by simply double >>>> clicking them." >>>> >>>> I saw a patch floating by to turn this on by default recently. Maybe >>>> we should make it off by default, but easy to turn on...? >>> >>> This would annoy all the people that the association targets. We can >>> either make it easy to run all Windows apps (malware and legit) via >>> file manager, or none at all. >> >> Yes, exactly. The default should be off, and it should be easy to >> turn on. >> - Dan > > I disagree on this point. Is malware via Wine on Linux really a > problem commonly affecting users? What happened to replicated > Window's behavior bug for bug? User X might ask: double clicking an > exe works in Windows why shouldn't it in Linux? Why should user X > have to go through an extra step to do something on Linux than they > would on Windows? > I posted my opinion on the matter on my blog. It basically says "Try to make like XP SP2 for downloaded files, but do it for files on drives marked as noexec as well" http://blog.mohag.net/2009/02/sane-rules-for-determining-likely.html Gert

Feb. 25, 2009

Re: Malware on Wine review

by Scott Ritchie

Chris Robinson wrote: > On Tuesday 24 February 2009 6:07:08 pm Scott Ritchie wrote: >> When I brought this up at the Ubuntu Developer Summit a while back, the >> security conscious there wanted to check an executable for the execute >> bit before launching it with Wine. Then, the user would be prompted if >> they wanted to run it, and if yes the execute bit would be set and the >> program launched. > > Seems a bit too easy to me for this to be ineffective. It's been repeated > often around here how people, especially Windows users, are conditioned to > click "Yes" and not actually see or comprehend what they're clicking yes too > ("I thought it was going to open it in notepad, not run it!"). IMHO, it would > be better if they had to take the initiative to mark it +x, then run it again. > That would prevent these kinds of surprises. > It would also make it completely unusable. Remember, all downloaded executables (even intentionally downloaded ones) will be -x by default. Do you really expect users to go right click->properties->permissions->allow execution? Or will they just conclude that it doesn't work. Worse, you could actively irritate them - suppose they do double click and you DONT offer the ability to open it, but instead instruct them to go through that annoying procedure. >> This check would be skipped if you clicked a link on the start menu >> (since you obviously meant to launch a program then). > > Not necessarily. Along with the .desktop trojan, the blog I read also showed > how to override system menu entries (by placing a replacement in the local > folder which will override the system one). So the link you clicked on may not > be what you intended.. > > But in order to do that a malicious script has to already be running! Such a system is already owned. Thanks, Scott Ritchie

Feb. 25, 2009

Re: Malware on Wine review

by Chris Robinson

On Tuesday 24 February 2009 6:07:08 pm Scott Ritchie wrote: > When I brought this up at the Ubuntu Developer Summit a while back, the > security conscious there wanted to check an executable for the execute > bit before launching it with Wine. Then, the user would be prompted if > they wanted to run it, and if yes the execute bit would be set and the > program launched. Seems a bit too easy to me for this to be ineffective. It's been repeated often around here how people, especially Windows users, are conditioned to click "Yes" and not actually see or comprehend what they're clicking yes too ("I thought it was going to open it in notepad, not run it!"). IMHO, it would be better if they had to take the initiative to mark it +x, then run it again. That would prevent these kinds of surprises. > This check would be skipped if you clicked a link on the start menu > (since you obviously meant to launch a program then). Not necessarily. Along with the .desktop trojan, the blog I read also showed how to override system menu entries (by placing a replacement in the local folder which will override the system one). So the link you clicked on may not be what you intended..

Feb. 25, 2009

Re: Malware on Wine review

by Dan Kegel

On Tue, Feb 24, 2009 at 6:07 PM, Scott Ritchie <scott(a)open-vote.org> wrote: > When I brought this up at the Ubuntu Developer Summit a while back, the > security conscious there wanted to check an executable for the execute > bit before launching it with Wine. Then, the user would be prompted if > they wanted to run it, and if yes the execute bit would be set and the > program launched. > > This check would be skipped if you clicked a link on the start menu > (since you obviously meant to launch a program then). Sounds good. A helper app could do this for us, I think. > That said, there's no point becoming "safe" until the desktop also > disables single click running of .desktop files that don't have the > execute bit set. It's trivial to write a piece of Linux malware that > does whatever you want by making it a .desktop file - you can even make > it so it displays as whatever name you like (and not foo.desktop). Right. Both changes are needed, the .desktop one more urgently. - Dan

Feb. 25, 2009

Re: Malware on Wine review

by Chris Robinson

On Tuesday 24 February 2009 6:01:53 pm Marcel Partap wrote: > Actually, nowadays there are most sophisticated technical solutions > which mount on a single click. No warning, no options. There are options. Whether or not said options are pre-configured sanely is another question; but that's up to the distributor. And it wouldn't be the first time distributions have made questionable decisions that have given grief to Wine. > > (or the CD was made wrong). > > uuhhm f.e. ISO9660 right? I have an ISO9660 disc, and the files on it show +x... > while i agree logically EXE files _should_ be flagged x aswell in > practice requiring the flag ties wine's functionability to close to > the randomness that is the user's choice of distrobution and its > default mount options. Starting to require +x from the next release on > is sure to break a lot of those systems. What would it break? A properly mounted CD should have +x on the exe's if you're trying to run them, and a downloaded installer can be given +x simple enough. And as mentioned before, Wine does a very good job of making sure installed programs get +x.

Feb. 25, 2009

Re: Malware on Wine review

by Scott Ritchie

Dan Kegel wrote: > On Mon, Feb 23, 2009 at 4:00 PM, Ben Klein <shacklein(a)gmail.com> wrote: >>>>> http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows… >>>>> >>>>> "Do not set the file association for Windows executables with Wine. >>>>> This would enable running Windows executables in Wine by simply double >>>>> clicking them." >>> Yes, exactly. The default should be off, and it should be easy to >>> turn on. >> And if we're willing to deal with an influx of users complaining why >> it doesn't work like that any more, we should do it. We'd probably >> also have to get all the package maintainers on board though. > > Yes, this will require a modicum of consensus. We might decide > to stay unsafe, or we might decide to make the bindings be in > a separate package, so it's easier for admins to flip the switch. > >> My packaging process doesn't do anything that explicitly associates >> Wine with exes, but I just tried opening an exe from Thunar and it ran >> ... interesting. Debian, 1.1.15 > > Yep. > - Dan > > When I brought this up at the Ubuntu Developer Summit a while back, the security conscious there wanted to check an executable for the execute bit before launching it with Wine. Then, the user would be prompted if they wanted to run it, and if yes the execute bit would be set and the program launched. This check would be skipped if you clicked a link on the start menu (since you obviously meant to launch a program then). That said, there's no point becoming "safe" until the desktop also disables single click running of .desktop files that don't have the execute bit set. It's trivial to write a piece of Linux malware that does whatever you want by making it a .desktop file - you can even make it so it displays as whatever name you like (and not foo.desktop). Thanks, Scott Ritchie

Feb. 25, 2009

Re: Malware on Wine review

by Chris Robinson

On Tuesday 24 February 2009 5:51:59 pm Ben Klein wrote: > Not correct. I've tested with vfat and ext2 filesystems, with noexec, > and the files are still marked +x. As it turns out, noexec doesn't > filter +x, just prevents shell/ld.so/kernel from loading the program. > Wine is an indirect method of loading a program in comparison. > > An interesting point, assuming that /mnt/test is mounted noexec: > $ /mnt/test/test.sh > bash: /mnt/test/test.sh: /bin/sh: bad interpreter: Permission denied > > $ sh /mnt/test/test.sh > Script runs That is interesting.. > So maybe this is a matter of semantics: is Wine an executable handler > (note binfmt-misc) or an executable interpreter? Should the Windows > application, when passed as an argument to Wine, behave as if it's > been called directly, or should it behave as if the executable has > been passed to an interpreter (i.e., interpreter reads and processes > the file as opposed to executing it directly)? I would say it's as if it's called directly. After all, Wine Is Not an Emulator (and by extension, an interpreter). :) The program is run by the system, not Wine.. Wine basically just loads it into memory so the system can run it.

Feb. 25, 2009

Re: Malware on Wine review

by Marcel Partap

On 25/02/09 02:35, Chris Robinson wrote: > On Tuesday 24 February 2009 4:54:26 pm Ben Klein wrote: >> "Unsolicited" files will get +x with default mount options on vfat/fat >> partitions, because ALL files on such partitions get +x this way. > > You have to mount a partition to get access to its files. A partition normally > doesn't mount itself, unless you had previously set it up to do so. As such, > you're actively trying to get the files.. they aren't just given to you > without warning. Actually, nowadays there are most sophisticated technical solutions which mount on a single click. No warning, no options. > >> I would at least like to see Wine respect noexec, if possible. I >> understand concerns about Wine respecting +x, due mainly to CD-based >> installers that may or may not have +x set on the files, but I think >> it would also be the *correct* thing to do. > > The (no)exec mount options are for specifying whether the executable bit is > masked out or not. Filesystems like NTFS/FAT/ISO9660 do not have an executable > bit (a shortcoming on their part), so it's always assumed to be on; the > (no)exec options, in turn, control whether or not the the bit gets filtered > out (ie. it determines whether the files get +x or not). To honor 'noexec' > means Wine should honor +x. > > If a user is trying to execute a program on a CD that's not +x, they mounted > it wrong Yeah...by clicking on that shiny 'optical disc drive' icon. > (or the CD was made wrong). uuhhm f.e. ISO9660 right? > I mean, assume it was a Linux program > they were trying to run on a CD instead of a Windows one. If the file doesn't > have +x, it won't run. > There's no reason a Windows program executed with Wine > should act differently than a Linux program executed directly. ..other than the fact that windows doesn't have the concept of an executable flag beyond the EXE extension. And wine as the linux executable that is actually being run *does* have the +x bit set... while i agree logically EXE files _should_ be flagged x aswell in practice requiring the flag ties wine's functionability to close to the randomness that is the user's choice of distrobution and its default mount options. Starting to require +x from the next release on is sure to break a lot of those systems. -- "Obstacles are those frightful things you see when you take your eyes off your goal." -- Henry Ford (1863-1947) Change the world! Vote: http://hfopi.org/vote-future

Feb. 25, 2009

Re: Malware on Wine review

by Ben Klein

2009/2/25 Chris Robinson <chris.kcat(a)gmail.com>: > On Tuesday 24 February 2009 4:54:26 pm Ben Klein wrote: >> "Unsolicited" files will get +x with default mount options on vfat/fat >> partitions, because ALL files on such partitions get +x this way. > > You have to mount a partition to get access to its files. A partition normally > doesn't mount itself, unless you had previously set it up to do so. As such, > you're actively trying to get the files.. they aren't just given to you > without warning. > >> I would at least like to see Wine respect noexec, if possible. I >> understand concerns about Wine respecting +x, due mainly to CD-based >> installers that may or may not have +x set on the files, but I think >> it would also be the *correct* thing to do. > > The (no)exec mount options are for specifying whether the executable bit is > masked out or not. Filesystems like NTFS/FAT/ISO9660 do not have an executable > bit (a shortcoming on their part), so it's always assumed to be on; the > (no)exec options, in turn, control whether or not the the bit gets filtered > out (ie. it determines whether the files get +x or not). To honor 'noexec' > means Wine should honor +x. Not correct. I've tested with vfat and ext2 filesystems, with noexec, and the files are still marked +x. As it turns out, noexec doesn't filter +x, just prevents shell/ld.so/kernel from loading the program. Wine is an indirect method of loading a program in comparison. An interesting point, assuming that /mnt/test is mounted noexec: $ /mnt/test/test.sh bash: /mnt/test/test.sh: /bin/sh: bad interpreter: Permission denied $ sh /mnt/test/test.sh Script runs So maybe this is a matter of semantics: is Wine an executable handler (note binfmt-misc) or an executable interpreter? Should the Windows application, when passed as an argument to Wine, behave as if it's been called directly, or should it behave as if the executable has been passed to an interpreter (i.e., interpreter reads and processes the file as opposed to executing it directly)? > If a user is trying to execute a program on a CD that's not +x, they mounted > it wrong (or the CD was made wrong). I mean, assume it was a Linux program > they were trying to run on a CD instead of a Windows one. If the file doesn't > have +x, it won't run. There's no reason a Windows program executed with Wine > should act differently than a Linux program executed directly. I agree with this entirely :D

Feb. 25, 2009

Re: Malware on Wine review

by Chris Robinson

On Tuesday 24 February 2009 4:54:26 pm Ben Klein wrote: > "Unsolicited" files will get +x with default mount options on vfat/fat > partitions, because ALL files on such partitions get +x this way. You have to mount a partition to get access to its files. A partition normally doesn't mount itself, unless you had previously set it up to do so. As such, you're actively trying to get the files.. they aren't just given to you without warning. > I would at least like to see Wine respect noexec, if possible. I > understand concerns about Wine respecting +x, due mainly to CD-based > installers that may or may not have +x set on the files, but I think > it would also be the *correct* thing to do. The (no)exec mount options are for specifying whether the executable bit is masked out or not. Filesystems like NTFS/FAT/ISO9660 do not have an executable bit (a shortcoming on their part), so it's always assumed to be on; the (no)exec options, in turn, control whether or not the the bit gets filtered out (ie. it determines whether the files get +x or not). To honor 'noexec' means Wine should honor +x. If a user is trying to execute a program on a CD that's not +x, they mounted it wrong (or the CD was made wrong). I mean, assume it was a Linux program they were trying to run on a CD instead of a Windows one. If the file doesn't have +x, it won't run. There's no reason a Windows program executed with Wine should act differently than a Linux program executed directly.

Feb. 25, 2009