Process for reporting security bugs?

[Please cc: me on any replies since I'm not subscribed to the list.]

Hi,

Is there a specific process for reporting security-related bugs in Wine?
I've looked through winehq.org but haven't found any mention of such; I
just wanted to make sure I haven't overlooked anything before posting the
bug in a publicly visible manner.

Thanks,

--Andrew Church
    [e-mail]
    http://achurch.org/

[Marcus Meissner]

Hi,

On Sat, Aug 10, 2013 at 01:12:24PM +0900, Andrew Church wrote:
> [Please cc: me on any replies since I'm not subscribed to the list.]
>
> Hi,
>
> Is there a specific process for reporting security-related bugs in Wine?
> I've looked through winehq.org but haven't found any mention of such; I
> just wanted to make sure I haven't overlooked anything before posting the
> bug in a publicly visible manner.

There is no such process set up for Wine yet.

If you want to report a thing privately, you could mail our chief in command,
Alexandre Julliard  privately and perhaps CC me
as I am a security guy at SUSE ;)

If it is not a high severe issue you can also just mail this mailinglist
here (wine-devel).

Ciao, Marcus

Hi Marcus,
> If it is not a high severe issue you can also just mail this mailinglist
> here (wine-devel).

Thanks for the info.  As it turns out, it's an already-known issue
(unixfs allows full host filesystem access through Windows APIs even if
there's no equivalent dosdevices link -- reported as
http://bugs.winehq.org/show_bug.cgi?id=22450) so I just added a comment
onto the bug.

Thanks,

--Andrew Church
    [e-mail]
    http://achurch.org/

[Marcus Meissner]

On Mon, Aug 12, 2013 at 10:40:48PM +0900, Andrew Church wrote:
> Hi Marcus,
> > If it is not a high severe issue you can also just mail this mailinglist
> > here (wine-devel).
>
> Thanks for the info.  As it turns out, it's an already-known issue
> (unixfs allows full host filesystem access through Windows APIs even if
> there's no equivalent dosdevices link -- reported as
> http://bugs.winehq.org/show_bug.cgi?id=22450) so I just added a comment
> onto the bug.

Depending on what attack scenario you envision, disabling unixfs is not enough.

If you want to avoid actually executed malware from accessing the UNIX fs directly,
you are out of luck as the malware could just do systemcalls itself (int 0x80 on x86 
for instance).

Remember Wine is made to execute Win32 code. ;)

If you think indirectly executed unixfs shellfolder accesses, this might be blocked
by that, yes.

Ciao, Marcus

> Depending on what attack scenario you envision, disabling unixfs is not enough.
>
> If you want to avoid actually executed malware from accessing the UNIX fs directly,
> you are out of luck as the malware could just do systemcalls itself (int 0x80 on x86 
> for instance).

Yup, I'm aware of that -- if I'm going to run potentially malicious code
I'll run it in a VM. (:  My concern is more for cases like otherwise
well-behaved programs that passively report to some remote server what
they see, such as when listing folders via the shell interface -- ideally
I'd like to limit what they see without the overhead of setting up a full
VM.

Might it be worth adding a note about both unixfs and the syscall issue
to the documentation?  The only reference I found to host filesystem
access is under section 4.1.4 "Drive Settings".  Maybe add some text like:

"""
Wine also provides a Windows share which allows modern applications to
access native Unix paths even without a drive mapping.  This will show up
as "/" in file dialogs.

Note that removing the default "z:" drive mapping will NOT prevent Windows
applications from reading your entire filesystem!  In addition to the
Windows share, malicious programs could detect that they are running under
Wine and execute native Linux system calls to get around any restrictions
imposed by Wine.  Consider running programs you don't trust in a virtual
machine instead.
"""

Just a thought,

--Andrew Church
    [e-mail]
    http://achurch.org/

[Rosanne DiMesio]

On Mon, 12 Aug 2013 23:29:51 JST
[e-mail] (Andrew Church) wrote:
> Note that removing the default "z:" drive mapping will NOT prevent Windows
> applications from reading your entire filesystem!  In addition to the
> Windows share, malicious programs could detect that they are running under
> Wine and execute native Linux system calls to get around any restrictions
> imposed by Wine.  Consider running programs you don't trust in a virtual
> machine instead.
> """

Already in the FAQ:

11.2. How good is Wine at sandboxing Windows apps?

Wine does not sandbox in any way at all. When run under Wine, a Windows app can do anything your user can. Wine does not (and cannot) stop a Windows app directly making native syscalls, messing with your files, altering your startup scripts, or doing other nasty things.

You need to use AppArmor, SELinux or some type of virtual machine if you want to properly sandbox Windows apps.