Wine securityflaw.

Ove Kaaven ovehk at ping.uio.no
Fri Nov 1 07:23:00 CST 2002


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.

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

> I fear the latter, if for no other reason that the performance would
> probably suck if *everything* was marshalling back and forth to
> wineserver.

It did, before Alexandre made some improvements (like shared memory and
caching of file handles). It still does in some cases. But there are
reasons other than security (like Windows's crappy IPC model) why
everything must go through the wineserver, so it was a necessary evil (yet
not so evil if it can help security, I guess)

> I'm not necessarily suggesting any of the above should be implemented in
> that form - but I certainly think having Wine's PE-loader let win32
> applications bind directly to native libraries (glibc for example) make
> the security and flexibility elements of all this disappear quite
> quickly.

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




More information about the wine-devel mailing list