Hi project,<br><br>Following the two previous threads, I am posting here a draft patch implementing my proposal.<br><br>So, to begin with I will remind you the principle :<br><br> All function callable from outside wine, should be added sanity checks :<br>
<br> if safe_mode_on and (sanity_check1_failed or sanity_check2_failed [...] ) <br> {<br> ExitWineCleanlyAndAdvertiseUser;<br> }<br><br> safe_mode_on value being read from registry (one and only time at wine startup).<br>
<br> So if safe_mode_on is set to true, sanity check are performed and in case of failure wine advertise user and terminate cleanly<br> Else, sanity check aren't performed and on a bad input wine is crashing.<br>
<br>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).<br>My goal here is firstly to demonstrate feasibility (hardly reached) and usefulness of the proposal. Secondly it is to provide something concrete. <br>
<br>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)<br><br>I tested the two modes with the help of wine test suite, restricted to kernel/file.c, test_overlapped and I considered only :<br>
all must-be-successful tests<br> GetOverlappedResult(0, NULL, &result, FALSE);<br> GetOverlappedResult(0, &ov, NULL, FALSE);<br>(these last two cannot be used in the same run, in either mode)<br><br>Results are as follow (test are wine_test calls wine on linux(1) platform only ) :<br>
1 - all must-be-successful tests 100% succeed in the two modes<br> 2 - in safe mode, the last two triggers the user message and wine exit<br> 3 - in unsafe mode, the last two triggers a crash<br><br>Consequently, based on theses results no regression is identified.<br>
<br>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 :<br><br>The problem I am considering (and I may be mistaken here as I am not an expert) is called "Unchecked Error Condition"(2) <br>
and it is a referenced weakness (CWE id 391), rated "Medium" in likelihood of exploit, by serious people.<br><br>Personally, I don't mind that Microsoft is ignoring it and promote usage of early crash or whatever. You are providing a <br>
software, presenting security defects that you choose not to fix because they are compliant with your goals.<br>Consequently, at the very least you should explicitly advertise your users, confronting them with their responsibilities. <br>
<br>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.<br>So user's advertisement about security is rather thin and implicit.<br>
<br>Please consider the problem, you need to do something about it, it is your responsibility.<br><br>And continue the good work, you rocks !<br>Guillaume<br> <br>(1) wine version : wine 1.1.14 with the attached patch applied on top of it<br>
OS : debian testing amd64<br>(2) <a href="http://cwe.mitre.org/data/definitions/391.html">http://cwe.mitre.org/data/definitions/391.html</a><br>(3) <a href="http://www.winehq.org/about/">http://www.winehq.org/about/</a><br>
<br>PS : I have observed that you are very active about fixing other security issues :<br> + buffer overflow<br> + NULL pointer dereference<br> + variable signedness<br> + ...<br>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".<br>