Wine securityflaw.

Vincent Béron vberon at
Fri Nov 1 10:51:08 CST 2002

Le ven 01/11/2002 à 11:27, Geoff Thorpe a écrit :
> Hi there,
> > 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.

> > is rather that glibc will still be loaded into the process's *address
> > space*, and thus a bad app could then get to it by searching for it in
> > memory or get to it through the Wine builtin DLLs.
> I understand the memory-scanning possibilities (just being able to find
> and corrupt wine-sensitive data is enough). However, if you sandbox
> those wine processes as a "nobody" user anyway, then any genuine
> attempts to bypass the wineserver-enforce policies would become a lot
> more difficult, ie. you'd be restricted to communicating with the
> wineserver and trying to convince it to do your nasty stuff for you.
> This is about the same problem as writing nasty code for MS windows.
> Moreover, the PE-loaded app doesn't get to execute its own code in the
> wineserver does it? If so, there's some merit to the approach David
> suggested.
> 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.

> IIUC, the answer to my PE-linkage question means the wineserver can
> enforce such rules unless the PE app uses "nasty" workarounds (eg.
> memory scanning assembly hacks)? The other answer you gave me suggests
> that if the PE apps could run in "nobody"-jailed processes, then there
> is even some protection against nasty workarounds (ie. the file-system
> and network policies become more genuinely, and less "voluntarily",
> secure)?

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,

> Cheers,
> Geoff
> -- 
> Geoff Thorpe
> geoff at

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


More information about the wine-devel mailing list