http://bugs.winehq.org/show_bug.cgi?id=19732
Summary: Security: use CAP_SYS_RAWIO during start up to map the memory below mmap_min_addr instead of permanently lowering it at install time Product: Wine Version: 1.1.21 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: scott@open-vote.org
Background:
In order to work around the mmap_min_addr setting introduced a while back that breaks Wine, many Wine packages now install conf files to /etc/sysctl.d/ that disable mmap_min_addr entirely. This reduces security of the system, as any kernel null pointer dereference bug can root the machine. One such bug was found to be open for 8 years.
This launchpad bug gives hints at what we need to do to implement this within Wine properly.
----
From Launchpad:
I would like to see wine and dosemu using filesystem capabilties to temporarily grant themselves CAP_SYS_RAWIO during start up to map the memory below mmap_min_addr, instead of requiring that the entire running system have their mmap_min_addr lowered.
Implementing this would involve two halves: setting up the filesystem capabilities when the package installed (postinst most likely), and dropping the capability once the program had allocated memory.
Here is a quick example of how to mark an executable with a capability:
http://www.friedhoff.org/posixfilecaps.html#Examples%20-%20Substitution%20of...
They use numeric values, but it may be more readable to use text version:
sudo setcap cap_sys_rawio=ep low-mmap
(setcap is in libcap2-bin)
Part 2 involves dropping the capability:
http://git.0pointer.de/?p=pulseaudio.git;a=blob;f=src/daemon/caps.c;hb=86dee...
the pa_drop_caps and shows how to drop capabilities, and pa_have_caps shows how to test for a specific capability. (In the example's case, CAP_SYS_NICE.)
(sorry, lost some context for my setcap paste: "low-mmap" is the program I was setting capabilities on. "cap_sys_rawio" is the textual version of the capabilities.)
http://bugs.winehq.org/show_bug.cgi?id=19732
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #1 from Dan Kegel dank@kegel.com 2009-08-15 13:54:47 --- Here's the link: https://bugs.launchpad.net/bugs/401950
http://bugs.winehq.org/show_bug.cgi?id=19732
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement
--- Comment #2 from Juan Lang juan_lang@yahoo.com 2009-08-15 16:10:22 --- This qualifies as an enhancement.
http://bugs.winehq.org/show_bug.cgi?id=19732
--- Comment #3 from Dmitry Timoshkov dmitry@codeweavers.com 2009-08-16 06:40:11 ---
In order to work around the mmap_min_addr setting introduced a while back that breaks Wine...
Wine has a workaround for that since a lot of time, there is no need for any fix.
http://bugs.winehq.org/show_bug.cgi?id=19732
Scott Ritchie scott@open-vote.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scott@open-vote.org
--- Comment #4 from Scott Ritchie scott@open-vote.org 2009-08-16 09:58:45 --- Are you saying that if I remove the disabling of mmap_min_addr entirely from the packaging Wine will continue to function as before? Do we no longer need the DOS memory area at all?
http://bugs.winehq.org/show_bug.cgi?id=19732
--- Comment #5 from Alexandre Julliard julliard@winehq.org 2009-08-16 12:31:20 --- (In reply to comment #4)
Are you saying that if I remove the disabling of mmap_min_addr entirely from the packaging Wine will continue to function as before? Do we no longer need the DOS memory area at all?
No, of course we need it. Though I'm not convinced that making Wine CAP_SYS_RAWIO is really safer than setting the mmap_min_addr to 0. It would need testing to see how early we can drop the capability, but if we have to load the DOS subsystem first then it's the same as not dropping it at all.
http://bugs.winehq.org/show_bug.cgi?id=19732
--- Comment #6 from Dan Kegel dank@kegel.com 2009-08-16 13:29:57 --- Maybe we could make
http://bugs.winehq.org/show_bug.cgi?id=19732
--- Comment #7 from Dan Kegel dank@kegel.com 2009-08-16 13:30:38 --- sorry, clicked 'save' instead of 'power off' :-)
http://bugs.winehq.org/show_bug.cgi?id=19732
--- Comment #8 from Scott Ritchie scott@open-vote.org 2009-08-16 19:36:09 --- I thought the security of CAP_SYS_RAWIO rather than mmap_min_addr wasn't to make Wine more secure, but to make the system more secure when Wine isn't running. The kernel bug above, for instance, was exploitable by non-wine programs if the user merely had Wine installed.
http://bugs.winehq.org/show_bug.cgi?id=19732
--- Comment #9 from Alexandre Julliard julliard@winehq.org 2009-08-17 04:38:23 --- (In reply to comment #8)
I thought the security of CAP_SYS_RAWIO rather than mmap_min_addr wasn't to make Wine more secure, but to make the system more secure when Wine isn't running. The kernel bug above, for instance, was exploitable by non-wine programs if the user merely had Wine installed.
Yes, but it doesn't make much difference, because all you have to do is to wrap the exploit in a DOS binary and run it with Wine. Either way, if Wine is installed you can exploit the bug. Dropping the caps wouldn't really help either, since you can't distinguish a malicious DOS app from a legitimate one. The only way is to not support DOS apps at all.
http://bugs.winehq.org/show_bug.cgi?id=19732
--- Comment #10 from Dan Kegel dank@kegel.com 2009-08-17 04:42:05 --- It matters a tiny bit. It might be harder to exploit the bug remotely if you have to inject a call to wine into Apache via a buffer overrun, say.
http://bugs.winehq.org/show_bug.cgi?id=19732
--- Comment #11 from Scott Ritchie scott@open-vote.org 2009-08-17 06:59:27 --- Moreover, a system could be secured using things that prevent arbitrary processes from invoking Wine (using, say, App Armor). So an exploit on one of those won't necessarily go all the way up.
http://bugs.winehq.org/show_bug.cgi?id=19732
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source
http://bugs.winehq.org/show_bug.cgi?id=19732
--- Comment #12 from Austin English austinenglish@gmail.com 2011-10-01 15:09:59 CDT --- This is your friendly reminder that there has been no bug activity for 1 year. Is this still an issue in current (1.3.29 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=19732
--- Comment #13 from Scott Ritchie scott@open-vote.org 2011-10-02 03:58:22 CDT --- Still an issue, still not important enough to spend time on.
http://bugs.winehq.org/show_bug.cgi?id=19732
--- Comment #14 from Dan Kegel dank@kegel.com 2011-10-02 09:36:14 CDT --- At some point, once wine's working really well, security will increase in importantce.
http://bugs.winehq.org/show_bug.cgi?id=19732
Marcus Meissner marcus@jet.franken.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marcus@jet.franken.de
--- Comment #15 from Marcus Meissner marcus@jet.franken.de 2012-03-12 17:04:34 CDT --- should not be an issue anymore, as we run DOSBOX for dos programs now?
http://bugs.winehq.org/show_bug.cgi?id=19732
Scott Ritchie scott@open-vote.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX
--- Comment #16 from Scott Ritchie scott@open-vote.org 2012-03-13 04:47:22 CDT --- Indeed, letting dosbox take care of it puts the problem out of our hands.
I'm a bit confused as to how dosbox is able to run apps without the same privilege escalation, though.
http://bugs.winehq.org/show_bug.cgi?id=19732
--- Comment #17 from Marcus Meissner marcus@jet.franken.de 2012-03-13 05:55:22 CDT --- dosbox runs a full cpu emulation, so it does not need page 0 mapped. (similar thing is done in dosemu in the current Ubuntu package btw)
you should probably drop the sysctl mmap_min-addr=0 setting from the Ubuntu wine packages before ubuntu security notices ;)
http://bugs.winehq.org/show_bug.cgi?id=19732
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED Resolution|WONTFIX |UPSTREAM
--- Comment #18 from Austin English austinenglish@gmail.com 2012-03-13 13:05:23 CDT --- UPSTREAM seems appropriate to me.