A basic implementation for increased security in wine proposal

[Guillaume SH]

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".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-devel/attachments/20090201/e300193c/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Basic-implementation-of-sanity-check.patch
Type: text/x-diff
Size: 2330 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20090201/e300193c/attachment.patch