Wine securityflaw.

[Geoff Thorpe]

Hi there,

On Friday 01 Nov 2002 8:23 am, Ove Kaaven wrote:
> On Thu, 31 Oct 2002, Geoff Thorpe wrote:
> > However, that still *requires* that the wineserver is actually doing
> > all the work and the wine processes that load and link PE images are
> > doing very little except marshalling the win32 API back and forth to
> > the wineserver. I'm not convinced that's the case but would be
> > thrilled to find out if it was. Ie. does wineserver handle all
> > translation from win32 to native? GUI? network? file-system?
>
> The wineserver doesn't do any GUI as such, but it does handle message
> queues. It's also responsible for handling win32 requests for opening
> files and creating network sockets. Win32 security is meant to go into
> the wineserver (if ever), so the model is already close to what you
> want, I guess.

Not too far by the sounds of things - still if the PE-loaded process is
the one creating and controlling windows there become permission
difficulties running it as a "nobody" user (and assembly hacks in the
PE-executables could still try to do nasty crap in an anti-wine
fashion if it has rights to your X-server). But at least this seems to
provide for file-system and network policy enforcement by the wineserver
process.

> > Or does some "permission-sensitive" functionality translation happen
> > directly from the PE-loaded processes by way of some linking-in of
> > Wine's win32 implementation?
>
> Maybe some, but no fundamental ones, I think. Any such could probably
> easily be rewritten.

Cool.

> 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.

> 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?

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)?

Cheers,
Geoff

-- 
Geoff Thorpe
geoff at geoffthorpe.net
http://www.geoffthorpe.net/