About Wine Security

[Vincent Povirk]

On Wed, Jan 7, 2015 at 2:56 PM, Pierre Schweitzer <pierre at reactos.org> wrote:
> Likely my 'crafted' word was poorly chosen. Here, I refer to a binary
> designed to exploit the flaws in Wine, as it would be designed to
> exploit flaws in any library.
> The user excepts to run a sane binary, whereas said binary will
> actually use its running context to corrupt memory, attempt to cause a
> denial of service in Wine, and so on. As for any other exploit (be it
> for a lib or another tool).

Typically, flaws in a library don't allow a program using the library
to do anything it couldn't do without access to that flaw. The
exception would be something like polkit which has privileged
components compared to the software using it.

All of Wine's components run as a single user, so flaws in them cannot
be exploited in this way.

I think we would be more worried about a scenario where a flaw in Wine
creates vulnerabilities in programs running in Wine. An example would
be if one of our image processing functions corrupted memory when
given some invalid data. This could be demonstrated using a test
program that reads an image using the Windows API, combined with
crafted image data that exploits the flaw.

The test program does not have to be designed to exploit a flaw, in
fact the problem is that it was designed to do something sane (read
and display an image), but an attacker supplying the image file can
make it do something else.

(Sorry if you already know all this, it's unclear based on what you've said.)