On Wed, Jan 7, 2015 at 2:56 PM, Pierre Schweitzer pierre@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.)