About Wine Security

Marcus Meissner meissner at suse.de
Wed Jan 7 10:19:10 CST 2015


On Wed, Jan 07, 2015 at 04:46:10PM +0100, Pierre Schweitzer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dear all,
> 
> I'm coming to you after a short discussion with Alexandre on this topic.
> 
> Wine gets more and more used, in various ways: either directly by
> users, or because it gets shipped in various form. It can packaged in
> a distribution, forked to suit a project needs (thinking about
> pipelight), or even shipped along with software to save native portage
> costs. Not to say that it's core of the ReactOS operating system itself.
> 
> But as any other software, Wine can present security vulnerabilities.
> MITRE exposes some of the code defects pattern (known as CWE) that can
> lead to potential exploitation and thus to security vulnerabilities
> [1]. When such defect is found and looks potentially exploitable
> (either because a crash was reported, or because it directly deals
> with callers data), a vulnerability ID (CVE) can be assigned by MITRE
> to reference the potential security vulnerability and make it known to
> people using it.
> 
> Some of them (buffer overflow, overrun, double-free, use-after-free,
> and so on) are sometimes found and fixed in Wine without further
> consideration regarding what it would imply for real Wine (mis-)usage.
> Even if no Proof of Concept is available at the time when the commit
> is made, it doesn't mean it cannot be exploited later on. With such
> exploits, it generally means that the attacker can target a Linux OS
> through a crafted PE binary.

> What I'm proposing here is that I start requesting CVE-ID for these
> findings when I find them in the commit logs of Wine and that they
> look exploitable. My hope is that it would allow distributions to
> repackage Wine taking care of these issues, but also to make people
> shipping Wine aware that the Wine they are shipping is likely
> vulnerable. This proposal it though limited in space & time: I
> wouldn't only do it starting in 2015 (I don't believe going backwards
> would make that much sense) and for 1.7 branch which is, I believe,
> the most used.
> 
> I'm looking for your feedback on my proposal and how you believe such
> vulnerabilities in Wine can affect the host Linux (or Mac).
> This wouldn't involve more work on your side (excepted if I ask for
> more details to make sure I'm right in my analysis of the issue).

I would say that exploiting by "crafted PE binary" is not in scope for
CVE allocation for Wine, as you would not keep the crafted PE binary
from doing "int 0x80" itself.

(Except of course when the binary crashes already the loader or imagehlp or so.)

But bugs in progressing any data leading to exploitation would be.

This is probably going to be tedious ;)

Ciao, Marcus



More information about the wine-devel mailing list