http://bugs.winehq.org/show_bug.cgi?id=25537
Summary: Wine allows access to / regardless configured ~/.wine/dosdevices Product: Wine Version: 1.3.9 Platform: All OS/Version: other Status: UNCONFIRMED Severity: critical Priority: P2 Component: wineserver AssignedTo: wine-bugs@winehq.org ReportedBy: t.artem@mailcity.com
Probably since 1.3.8 or 1.3.9 any Windows application can open (read/write/list/erase) any files in / (root) regardless user defined disk devices (under ~/.wine/dosdevices).
It's a huge security issue, because in the past you could erase z: -> / symbolic link and safely run any software (including malware).
This security measure has been removed without any explanations how to harden your Wine PREFIX.
http://bugs.winehq.org/show_bug.cgi?id=25537
Andrew Nguyen arethusa26@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|wineserver |-unknown Severity|critical |normal
--- Comment #1 from Andrew Nguyen arethusa26@gmail.com 2010-12-16 15:00:01 CST --- (In reply to comment #0)
Probably since 1.3.8 or 1.3.9 any Windows application can open (read/write/list/erase) any files in / (root) regardless user defined disk devices (under ~/.wine/dosdevices).
I can't reproduce this behavior for normal Win32 file accesses with a clean Wine prefix after running winetricks sandbox, which removes the z: symlink and a few others.
It's a huge security issue, because in the past you could erase z: -> / symbolic link and safely run any software (including malware).
Removing the z: symlink provides only illusory security benefits, as http://wiki.winehq.org/FAQ#head-3cb8f054b33a63be30f98a1b6225d74e305a0459 discusses.
This security measure has been removed without any explanations how to harden your Wine PREFIX.
http://bugs.winehq.org/show_bug.cgi?id=25537
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #2 from Alexandre Julliard julliard@winehq.org 2010-12-16 15:04:04 CST --- There has never been any such security measure.
http://bugs.winehq.org/show_bug.cgi?id=25537
--- Comment #3 from Artem S. Tashkinov t.artem@mailcity.com 2010-12-16 15:13:45 CST --- (In reply to comment #2)
There has never been any such security measure.
Pardon me, Julliard, but Wine _used to_ allow access to filesystems via configured dosdevices and Z: was the only way for Wine applications to access root fs.
Right now Wine exports "/" right on the desktop, thus negating the ability of denying Windows applications access to /.
If it wasn't a security measure then I'm fine with it.
However I'm eager to get any substitute of what was once available.
(In reply to comment #1)
(In reply to comment #0)
Probably since 1.3.8 or 1.3.9 any Windows application can open (read/write/list/erase) any files in / (root) regardless user defined disk devices (under ~/.wine/dosdevices).
I can't reproduce this behavior for normal Win32 file accesses with a clean Wine prefix after running winetricks sandbox, which removes the z: symlink and a few others.
Yes, I'm sorry. Even though / link on the desktop exists Wine doesn't allow to read files from /. OK. However the fact that Windows application can even list files under / is still a security weakness.
It's a huge security issue, because in the past you could erase z: -> / symbolic link and safely run any software (including malware).
Removing the z: symlink provides only illusory security benefits, as http://wiki.winehq.org/FAQ#head-3cb8f054b33a63be30f98a1b6225d74e305a0459 discusses.
This security measure has been removed without any explanations how to harden your Wine PREFIX.
Wine wiki states that:
Consider removing the default Wine Z: drive, which maps to the unix root directory. This is only a weak defense, but it might help against some attacks.
However I don't see any explanation as to why it's a weak defense. It's a perfect defense, because unless wine server allows hijacking its own code via direct memory access, no Wine application can leave the limits of predefined desdevices.
OK, it seems like everyone disagrees with my arguments, so let's abandon this feature.
http://bugs.winehq.org/show_bug.cgi?id=25537
--- Comment #4 from Artem S. Tashkinov t.artem@mailcity.com 2010-12-16 15:17:23 CST --- (In reply to comment #3)
Pardon me, Julliard, but Wine _used to_ allow access to filesystems via
I meant "Alexander". I'm terribly sorry for calling you this way.
http://bugs.winehq.org/show_bug.cgi?id=25537
--- Comment #5 from Juan Lang juan_lang@yahoo.com 2010-12-16 15:20:37 CST --- (In reply to comment #3)
Pardon me, Julliard, but Wine _used to_ allow access to filesystems via configured dosdevices and Z: was the only way for Wine applications to access root fs.
No, any app could invoke a Linux system call to access the filesystem directly.
http://bugs.winehq.org/show_bug.cgi?id=25537
--- Comment #6 from Artem S. Tashkinov t.artem@mailcity.com 2010-12-16 16:17:23 CST --- (In reply to comment #5)
(In reply to comment #3)
Pardon me, Julliard, but Wine _used to_ allow access to filesystems via configured dosdevices and Z: was the only way for Wine applications to access root fs.
No, any app could invoke a Linux system call to access the filesystem directly.
A valid point, but I'm not aware of any existing Windows malware which targeted Wine environment.
But since you are right I think a new feature request should be opened sounding this way:
"Wine needs to provide a true sandboxing functionality".
If it's advisable I'll open one.
Because I'm quite sure many people will greet this idea wholeheartedly.
http://bugs.winehq.org/show_bug.cgi?id=25537
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED Platform|All |Other
--- Comment #7 from Dmitry Timoshkov dmitry@codeweavers.com 2010-12-17 04:01:20 CST --- Closing invalid.
http://bugs.winehq.org/show_bug.cgi?id=25537
--- Comment #8 from Dmitry Timoshkov dmitry@codeweavers.com 2010-12-17 04:03:56 CST --- (In reply to comment #6)
But since you are right I think a new feature request should be opened sounding this way:
"Wine needs to provide a true sandboxing functionality".
If it's advisable I'll open one.
Because I'm quite sure many people will greet this idea wholeheartedly.
Wine is not a virtual machine, or aims to provide a virtual environment, such a request is invalid.
-
wine-bugs＠winehq.org