Hi project,

Following the two previous threads, I am posting here a draft patch implementing my proposal.

So, to begin with I will remind you the principle :

    All function callable from outside wine, should be added sanity checks :

    if safe_mode_on and (sanity_check1_failed or sanity_check2_failed [...] )
    {
        ExitWineCleanlyAndAdvertiseUser;
    }

    safe_mode_on value being read from registry (one and only time at wine startup).

    So if safe_mode_on is set to true, sanity check are performed and in case of failure wine advertise user and terminate cleanly
    Else, sanity check aren't performed and on a bad input wine is crashing.

I've only produced a basic implementation, clearly marking as TODO items left to be done (by the way they are too much for me to handle, as I am no match for you when it comes to implementation).
My goal here is firstly to demonstrate feasibility (hardly reached) and usefulness of the proposal. Secondly it is to provide something concrete. 

Please note than "unsafe" mode behave exactly the same than latest git version of wine (some more operations occur, however, so is not strictly equal in term of performance)

I tested the two modes with the help of wine test suite, restricted to kernel/file.c, test_overlapped and I considered only :
    all must-be-successful tests
    GetOverlappedResult(0, NULL, &result, FALSE);
    GetOverlappedResult(0, &ov, NULL, FALSE);
(these last two cannot be used in the same run, in either mode)

Results are as follow (test are wine_test calls wine on linux(1) platform only ) :
    1 - all must-be-successful tests 100% succeed in the two modes
    2 - in safe mode, the last two triggers the user message and wine exit
    3 - in unsafe mode, the last two triggers a crash

Consequently, based on theses results no regression is identified.

As I received some more informations in last thread (thank you for enhancing my comprehension of the problem), I will again expose the problem, taking them into account :

The problem I am considering (and I may be mistaken here as I am not an expert) is called "Unchecked Error Condition"(2)
and it is a referenced weakness (CWE id 391), rated "Medium" in likelihood of exploit, by serious people.

Personally, I don't mind that Microsoft is ignoring it and promote usage of early crash or whatever. You are providing a
software, presenting security defects that you choose not to fix because they are compliant with your goals.
Consequently, at the very least you should explicitly advertise your users, confronting them with their responsibilities.

I have read(3) on winehq a warning stating that wine is beta software, not ready for general use. I have read too about the "bug for bug" compatibility.
So user's advertisement about security is rather thin and implicit.

Please consider the problem, you need to do something about it, it is your responsibility.

And continue the good work, you rocks !
Guillaume
 
(1) wine version : wine 1.1.14 with the attached patch applied on top of it
    OS : debian testing amd64
(2) http://cwe.mitre.org/data/definitions/391.html
(3) http://www.winehq.org/about/

PS : I have observed that you are very active about fixing other security issues :
        + buffer overflow
        + NULL pointer dereference
        + variable signedness
        + ...
I seems to me that hopefully, you performs those fixes without consideration for "Is windows doing the same ?". I will be sad the day I will see a commit "Remove resource release because Windows is doing the same" or "Remove buffer overflow fix because app A (2 million copies sold) rely on it".