Another virus-in-wine story

[Dan Kegel-2]

This is about the fifth article of this sort, so it's not really news
anymore, but it's still fun to read about.

TFA is clueless about how to clean up a wine
installation (he thought uninstalling wine would do it),
buts lots of readers supply the missing clue.

http://linux.slashdot.org/story/09/10/24/1759213/Now-Linux-Can-Get-Viruses-Via-Wine

[nlaroche]

Dan Kegel wrote:

> This is about the fifth article of this sort, so it's not really news
> anymore, but it's still fun to read about.
>
> TFA is clueless about how to clean up a wine
> installation (he thought uninstalling wine would do it),
> buts lots of readers supply the missing clue.
>
> http://linux.slashdot.org/story/09/10/24/1759213/Now-Linux-Can-Get-Viruses-Via-Wine
>
>
>

A few months ago there was a topic in wine-devel on the same subject. A
toggle switch for portions of the wine API (i.e. networking),
WINEPREFIX, and SELinux seems to make this a non-issue.

The default wine SELinux configuration for Fedora 11 denies quite a bit
of behavior. (Try compiling and using HEAD without setting the security
context or entering permissive mode and you'll see what I mean).

Does this even need to be handled at the wine level to prevent
system-wide corruption? It seems like other security technologies
already provide this protection.

-Nick

[Dan Kegel-2]

On Sat, Oct 24, 2009 at 10:47 PM, Nicholas LaRoche <nlaroche@...> wrote:

> A few months ago there was a topic in wine-devel on the same subject. A
> toggle switch for portions of the wine API (i.e. networking), WINEPREFIX,
> and SELinux seems to make this a non-issue.
>
> The default wine SELinux configuration for Fedora 11 denies quite a bit of
> behavior. (Try compiling and using HEAD without setting the security context
> or entering permissive mode and you'll see what I mean).
>
> Does this even need to be handled at the wine level to prevent system-wide
> corruption? It seems like other security technologies already provide this
> protection.

We may want to lend a hand.  For instance, I could imagine
the system needing some help to figure out how to allow
certain windows apps access to the network, and deny it
to others.  And I think sandboxing a la chromium might end
up being a useful technique that would require some work on
wine's part to work well.
- Dan

[Scott Ritchie]

Dan Kegel wrote:

> On Sat, Oct 24, 2009 at 10:47 PM, Nicholas LaRoche <nlaroche@...> wrote:
>> A few months ago there was a topic in wine-devel on the same subject. A
>> toggle switch for portions of the wine API (i.e. networking), WINEPREFIX,
>> and SELinux seems to make this a non-issue.
>>
>> The default wine SELinux configuration for Fedora 11 denies quite a bit of
>> behavior. (Try compiling and using HEAD without setting the security context
>> or entering permissive mode and you'll see what I mean).
>>
>> Does this even need to be handled at the wine level to prevent system-wide
>> corruption? It seems like other security technologies already provide this
>> protection.
>
> We may want to lend a hand.  For instance, I could imagine
> the system needing some help to figure out how to allow
> certain windows apps access to the network, and deny it
> to others.  And I think sandboxing a la chromium might end
> up being a useful technique that would require some work on
> wine's part to work well.
> - Dan
>

Sandboxing is certainly an interesting idea if we want to expand the
role of Wine-specific packages (a la Picassa).  I've been experimenting
with shipping a Windows (or winelib) app via a distro package configured
to run in its own prefix.  This in particular could benefit from
sandboxing, as then security holes in that application wouldn't take
down the rest of the user folder.

Many apps don't need to view the user folder for documents but also
employ programmable scripting engines - a good example are games.  It
would be much more convenient to pass some sort of "sandbox me, allow
network, deny home folder access" switch to Wine than to muck about with
stuff like AppArmor profiles.

Thanks,
Scott Ritchie

[Dan Kegel-2]

On Sun, Oct 25, 2009 at 10:57 AM, Scott Ritchie <scott@...> wrote:
> It would be much more convenient to pass some sort of "sandbox me, allow
> network, deny home folder access" switch to Wine than to muck about with
> stuff like AppArmor profiles.

http://sandboxing.org/ was just formed to discuss such a thing...
- Dan

[Stefan Dösinger]

Am 25.10.2009 um 10:57 schrieb Scott Ritchie:
> Many apps don't need to view the user folder for documents but also
> employ programmable scripting engines - a good example are games.  It
> would be much more convenient to pass some sort of "sandbox me, allow
> network, deny home folder access" switch to Wine than to muck about  
> with
> stuff like AppArmor profiles.
The usual reply to this is that Windows apps in Wine can just issue  
Linux system calls, so any Wine-based sandboxing is security by  
obscurity. You need something at the syscall layer.

[nlaroche]

Scott Ritchie wrote:

> Dan Kegel wrote:
>> On Sat, Oct 24, 2009 at 10:47 PM, Nicholas LaRoche <nlaroche@...> wrote:
>>> A few months ago there was a topic in wine-devel on the same subject. A
>>> toggle switch for portions of the wine API (i.e. networking), WINEPREFIX,
>>> and SELinux seems to make this a non-issue.
>>>
>>> The default wine SELinux configuration for Fedora 11 denies quite a bit of
>>> behavior. (Try compiling and using HEAD without setting the security context
>>> or entering permissive mode and you'll see what I mean).
>>>
>>> Does this even need to be handled at the wine level to prevent system-wide
>>> corruption? It seems like other security technologies already provide this
>>> protection.
>> We may want to lend a hand.  For instance, I could imagine
>> the system needing some help to figure out how to allow
>> certain windows apps access to the network, and deny it
>> to others.  And I think sandboxing a la chromium might end
>> up being a useful technique that would require some work on
>> wine's part to work well.
>> - Dan
>>
>
> Sandboxing is certainly an interesting idea if we want to expand the
> role of Wine-specific packages (a la Picassa).  I've been experimenting
> with shipping a Windows (or winelib) app via a distro package configured
> to run in its own prefix.  This in particular could benefit from
> sandboxing, as then security holes in that application wouldn't take
> down the rest of the user folder.
>
> Many apps don't need to view the user folder for documents but also
> employ programmable scripting engines - a good example are games.  It
> would be much more convenient to pass some sort of "sandbox me, allow
> network, deny home folder access" switch to Wine than to muck about with
> stuff like AppArmor profiles.
>
> Thanks,
> Scott Ritchie
>

 From a usability standpoint, adding switches to wine for sandboxing is
a good thing. But it seems to only cover the APIs exported by wine. A
specially crafted win32 wine-aware malware app could leverage
sys_open(1) and sys_write(4) via int 80h to bypass this isolation and
install itself anywhere in the users home directory.

e.g. this malware could open ~/.bashrc and install linux specific
malware that executes the next time you open a shell.

Perhaps the app-specific package that you mentioned can be shipped with
an AppArmor/SELinux profile that prohibits syscalls from originating
anywhere in user code. (Assuming that the other sandboxing changes are
made to wine).

Should it be up to the distro maintainers to add these profiles?

-Nick

[David Gerard-2]

2009/10/25 Nicholas LaRoche <nlaroche@...>:

> From a usability standpoint, adding switches to wine for sandboxing is a
> good thing. But it seems to only cover the APIs exported by wine. A
> specially crafted win32 wine-aware malware app could leverage sys_open(1)
> and sys_write(4) via int 80h to bypass this isolation and install itself
> anywhere in the users home directory.
> e.g. this malware could open ~/.bashrc and install linux specific malware
> that executes the next time you open a shell.


Yes. It would be exceedingly foolish to claim to offer security that
cannot be delivered.

(I'd sugest big warnings. "WARNING: any Windows app can do anything on
your system that the user it is running as can do. If you want to
study malware, use WineZero or similar.")


> Perhaps the app-specific package that you mentioned can be shipped with an
> AppArmor/SELinux profile that prohibits syscalls from originating anywhere
> in user code. (Assuming that the other sandboxing changes are made to wine).


This would need some really serious testing before making such a
promise, of course. i.e., will Wine itself still work?


- d.

[Dan Kegel-2]

On Sun, Oct 25, 2009 at 2:18 PM, Nicholas LaRoche <nlaroche@...> wrote:
> A specially crafted win32 wine-aware malware app could leverage sys_open(1)
> and sys_write(4) via int 80h to bypass this isolation and install itself
> anywhere in the users home directory.

Yes.  That's why I don't think win32-only sandboxing is
sufficient.  A native sandbox is needed to provide any
real security.

sandboxing.org talks about various implementations
of native sandboxes for linux.  Chrome's, for example,
are described here:
http://sandboxing.org/?page_id=13
Many of them are based on chroot, but there are
also ones based on seccomp and selinux.

It would be interesting to, for instance, offer a truly
secure sandboxed wine to run ie7 in...
- Dan

[Scott Ritchie]

Stefan Dösinger wrote:

>
> Am 25.10.2009 um 10:57 schrieb Scott Ritchie:
>> Many apps don't need to view the user folder for documents but also
>> employ programmable scripting engines - a good example are games.  It
>> would be much more convenient to pass some sort of "sandbox me, allow
>> network, deny home folder access" switch to Wine than to muck about with
>> stuff like AppArmor profiles.
> The usual reply to this is that Windows apps in Wine can just issue
> Linux system calls, so any Wine-based sandboxing is security by
> obscurity. You need something at the syscall layer.
>

Could Wine ship two binaries, one with an AppArmor profile blocking
syscalls and one without?  Then a simple switch could tell Wine which
one to use and that functionality wouldn't need to be duplicated elsewhere.

Thanks,
Scott Ritchie

[nlaroche]

Scott Ritchie wrote:

> Stefan Dösinger wrote:
>> Am 25.10.2009 um 10:57 schrieb Scott Ritchie:
>>> Many apps don't need to view the user folder for documents but also
>>> employ programmable scripting engines - a good example are games.  It
>>> would be much more convenient to pass some sort of "sandbox me, allow
>>> network, deny home folder access" switch to Wine than to muck about with
>>> stuff like AppArmor profiles.
>> The usual reply to this is that Windows apps in Wine can just issue
>> Linux system calls, so any Wine-based sandboxing is security by
>> obscurity. You need something at the syscall layer.
>>
>
> Could Wine ship two binaries, one with an AppArmor profile blocking
> syscalls and one without?  Then a simple switch could tell Wine which
> one to use and that functionality wouldn't need to be duplicated elsewhere.
>
> Thanks,
> Scott Ritchie
>
>

Is there any valid use for syscalls in wine?

Most of the functionality that might be gained by using a syscall
directly probably already exists in libc or some other library. These
libraries can have granular security policies applied to them as opposed
to granting full access to the core wine binary.

-Nick

[Damjan Jovanovic-2]

On Mon, Oct 26, 2009 at 4:22 AM, Nicholas LaRoche <nlaroche@...> wrote:

> Scott Ritchie wrote:
>>
>> Stefan Dösinger wrote:
>>>
>>> Am 25.10.2009 um 10:57 schrieb Scott Ritchie:
>>>>
>>>> Many apps don't need to view the user folder for documents but also
>>>> employ programmable scripting engines - a good example are games.  It
>>>> would be much more convenient to pass some sort of "sandbox me, allow
>>>> network, deny home folder access" switch to Wine than to muck about with
>>>> stuff like AppArmor profiles.
>>>
>>> The usual reply to this is that Windows apps in Wine can just issue
>>> Linux system calls, so any Wine-based sandboxing is security by
>>> obscurity. You need something at the syscall layer.
>>>
>>
>> Could Wine ship two binaries, one with an AppArmor profile blocking
>> syscalls and one without?  Then a simple switch could tell Wine which
>> one to use and that functionality wouldn't need to be duplicated
>> elsewhere.
>>
>> Thanks,
>> Scott Ritchie
>>
>>
> Is there any valid use for syscalls in wine?
>
> Most of the functionality that might be gained by using a syscall directly
> probably already exists in libc or some other library. These libraries can
> have granular security policies applied to them as opposed to granting full
> access to the core wine binary.
>
> -Nick
>
>
>

server/fd.c:

static inline int epoll_create( int size )
{
    int ret;
    __asm__( "pushl %%ebx; movl %2,%%ebx; int $0x80; popl %%ebx"
             : "=a" (ret) : "0" (254 /*NR_epoll_create*/), "r" (size) );
    SYSCALL_RET(ret);
}

So yes we do syscalls straight from wine.

Damjan

[Marcus Meissner-4]

On Sun, Oct 25, 2009 at 06:14:34PM -0700, Scott Ritchie wrote:

> Stefan Dösinger wrote:
> >
> > Am 25.10.2009 um 10:57 schrieb Scott Ritchie:
> >> Many apps don't need to view the user folder for documents but also
> >> employ programmable scripting engines - a good example are games.  It
> >> would be much more convenient to pass some sort of "sandbox me, allow
> >> network, deny home folder access" switch to Wine than to muck about with
> >> stuff like AppArmor profiles.
> > The usual reply to this is that Windows apps in Wine can just issue
> > Linux system calls, so any Wine-based sandboxing is security by
> > obscurity. You need something at the syscall layer.
> >
>
> Could Wine ship two binaries, one with an AppArmor profile blocking
> syscalls and one without?  Then a simple switch could tell Wine which
> one to use and that functionality wouldn't need to be duplicated elsewhere.

AppArmor does not do system call level blocking.

You could use AA to confine an app to write just in $HOME/.wine/ itself.

Ciao, Marcus

[Detlef Riekenberg]

On Sa, 2009-10-24 at 22:07 -0700, Dan Kegel wrote:
> This is about the fifth article of this sort, so it's not really news
> anymore, but it's still fun to read about.
> http://linux.slashdot.org/story/09/10/24/1759213/Now-Linux-Can-Get-Viruses-Via-Wine

The blogger mention the bad website, but the malware file change to
often.

Yesterday, you will get a fake "Adobe Flash Player.exe" (crash early in
Wine)
after redirection to a different Website (looks like facebook.com):
http://www.virustotal.com/analisis/a7c8ccfd07652f8622edb3f7ea2bbb975ddb3a74df90feca794e71d2001bbe24-1256993159

Today, you will receive "surprise.exe" (crash early in Wine) from the
Website:
http://www.virustotal.com/analisis/8f753cbb1ddc3edda4a0b4ec0ce14475c2ed5e5890864f1d31ea8eefa28d01b2-1256994557


--
 
By by ... Detlef