Process for reporting security bugs?

Andrew Church achurch+wine-devel at achurch.org
Mon Aug 12 23:29:51 CDT 2013


>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
    achurch at achurch.org
    http://achurch.org/



More information about the wine-devel mailing list