Wine securityflaw.

Geoff Thorpe geoff at
Fri Nov 1 13:20:10 CST 2002

On Friday 01 Nov 2002 11:51 am, Vincent Béron wrote:
> Le ven 01/11/2002 à 11:27, Geoff Thorpe a écrit :
> > Hi there,
> [snip]
> > > What do you mean? No PE apps can link straight to glibc. Only
> > > Unix-implemented DLLs (like the Wine ones) can link to it. The
> > > problem
> >
> > Ah, this had been my question. It seemed otherwise from the earlier
> > post I had seen. I'm glad this is the case - you need to use
> > virus-style hacks if you want your PE app to bypass (or corrupt) the
> > interfaces provided by Wine libraries.
> No. Just launch a Winelib app from the PE (it must be permissible to do
> so), and that Winelib app then has access to glibc and friends, and can
> act as a gateway between the main app and the outside (the sandbox)
> world. That app could be meant as an "enhancement" or "workaround" when
> running under Wine (thus not affecting normal Windows operation), but
> still have a "bug" which can do nasty things.

In what way is that different from what I said? It's a wine-specific
work-around - the winelib app you invoke is either wine-provided (ie.
not a problem) or a wine-specific payload your application is carrying.
This is equivalent to embedding assembly hacks (after all, your assembly
hacks could be a complete winelib app image that you save to a file and

I don't see the issue of executing winelib apps as a fundamental
security problem as such - for example, what if your policy says not to
load executables or libraries from "C:\\" unless they're PE format?
Likewise, what is to stop you defining a policy that wineserver-managed
applications can't execute winelib apps unless they're (a) provided by
wine (/usr/lib/wine/... and not C:\\...), or (b) you've specifically
granted them rights to do so.

The point remains that to do damage, applications have to implement very
deliberate wine-targetted workaround measures if they don't want to be
subject to policies configured by the user (and enforced by wineserver).
By "deliberate", I mean they have to detect the wine environment (memory
scanning, "signature" characteristics of unimplemented or buggy win32
API functions, etc) before then delivering their "special" payload. Ie.
they have to write anti-wine viruses. Moreover, jailing the
non-wineserver processes (if possible) to a "nobody" user makes it
*possible* to provide some actual protection against such untrusted PE
win32 apps. Not that *possible* means *default* of course :-)

OTOH: If an application is written to have wine-specific functionality
and you want to accept it, that's something you could support. Kind of
like turning MS's "embrace and extend" policy against themselves - allow
applications to support Wine-specific enhancements that can't be used in
MS windows. But in this situation, you're trusting and accepting both
win32 *AND* native code - and you're not any more exposed than if you
were just trusting a native application.

My point against anti-wine measures, I think, remains. If you are forced
to run untrusted (ie. potentially anti-wine) binaries, there seems to be
a lot that can be done on two levels; first, forcing anti-wine measures
to be explicit payload-bearing virii and not just annoying "features".
Second, jailing PE-loaded code with user privileges so that only the
wineserver has all the native (unix) permissions of your regular user
account. The first is a criminal (and complexity) deterrent. The second
is an actual hardening of wine's security model.

> > So essentially I guess we could specify, for example, that no
> > wine-loaded application has access to "F:" unless it is enabled in
> > the wine command-line arguments? Eg.
> >
> >     wine --config-section=enable-F-home  C:\\...
> >
> > where 'enable-F-home' could be a section in the config file
> > specifying to map F: to $HOME?
> Remember (from the thread on 0.8.0 feature list) that the config file
> should be merged completely in the registry, with a control-panel like
> app to aaply changes. So at least that app will need to be able to
> access it read/write.

Doesn't the wineserver process handle all registry manipulation? If so,
the wineserver doesn't even have to let the applications get file-access
to the registry - but either way, if it's the wineserver, you can
implement a policy however you like without worrying about nasty
workarounds embedded in the PE images. That policy could be an "override
the registry settings in situation XXX" type of thing, or simply built
in to the registry configuration model (the wineserver would just have
to refuse to manipulate those entries if asked to by (untrusted)
applications). You could even write a win32 configuration GUI that would
manipulate these entries, then set your policy to allow *only* that
application to touch them.

> Is it even possible to switch to the nobody user without having higher
> priviledges beforehand? I thought you needed to be launched by root (or
> SUID root, etc.) to switch to nobody, since it can't login (su, ssh,
> etc.)

There is always a way :-) You could chmod 4755 the wine binary and wine
itself could setuid back down to the "regular" user when initialising
the wineserver and could setuid down to "nobody" when initialising the
PE-loader. By the way, processes started as root that drop use
privileges (on most posixy systems) become very hard to run memory
scanning attacks and a variety of other things an anti-wine virus writer
would find useful (it's also harder to attach a debugger to). If the
wineserver needs to be able to create extra "nobody" processes later
then there's probably a different way of doing this - eg. make the
PE-loader be a chmod 4755 binary so it can start as root and fold down
to "nobody" - then it can be invoked by the "normal" user, including the
wineserver process(es).

> Just my 0.02 $ (yes, $ after. Do you say "dollar 3.56"? Neither do we
> in French :)

moi non-plus en anglais - mais c'est surement "0,02 $", non? :-)


Geoff Thorpe
geoff at

More information about the wine-devel mailing list