2009/2/1 Marcus Meissner marcus@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