A basic implementation for increased security in wine proposal

[Reece Dunn]

2009/2/1 Marcus Meissner <marcus at jet.franken.de>:
> On Sun, Feb 01, 2009 at 10:41:25AM +0100, Guillaume SH wrote:
>>
>> Running this application on wine, I get to have my crash, with the
>> possibility of an exploit. So all I have to do know is to find a vector to
>> make you and some other people willing to run my application.
>>
>> I won't describe in detail the way to perform the exploit as :
>>       1 - I don't know how to proceed and I don't want to
>>       2 - It would be showing poor sense of responsibilities
>
> If you can run an application ... it already can do everything!
>
> No need to protect APIs against misuse, they run at the same privilege
> level as your code.

What exactly is being exploited?

Can you use this as a basis to inject your own code to change Wine's
behaviour (e.g. using a buffer overflow exploit)?
Can you use this to gain root privileges from a non-root user?
Can you use it to gain access to or modify sensitive data?

What you have at the moment is an application that crashes. A crash could be:
  (a) because Wine is wrong and needs to be fixed (see the Coverity
NULL pointer patches);
  (b) because the application is wrong - the application needs to be
fixed here, not Wine;
  (c) someone has tampered with the system.

Taking your example of passing a NULL to GetOverlappedResult is that
*even though the MSDN documentation does not mention that these
parameters are optional (indicating they must be valid)* you are
recommending that Wine makes these parameters optional. This has the
effect of hiding bugs in the native application - for case (b) - or
making them harder to track down. You are also making case (c) have
potentially successful results as this is saying "not a problem, carry
on".

If you report - as has been suggested - to the user, how is this
useful to them? Can that be subverted to do malicious things? Why add
to the code, providing something that has to be added to every API,
that just increases the code size. How can you investigate and debug
here?

If someone tampered this to say "do nothing, instead of reporting to
the user" then you have lost this mechanism and you have turned a fail
case into a success case and the application could then potentially do
more damage.

There have been some attempts to add DrWatson functionality that will
trap the exceptions (using a separate, overridable process), show the
user it has crashed and gather information for a bug report. This is
the same mechanism that winedbg uses to give the crash dump, and other
debug tool. This is the best way to go for something like this -
having a crash report program that displays a "report this to Wine
developers" dialog. Microsoft, Mozilla and others use this approach.

- Reece