April 2008 - Wine-Devel - list.winehq.org

Re: wineserver socket file and DOS attacks

by Ove Kaaven

Maarten Lankhorst skrev: > The latter won't work, they could create the directory and then delete > it after wineserver started. I don't think it is really a problem, by > the time someone else can put that directory in /tmp chances are that > they can do a lot more malicious things then just making Wine refuse > to run. Like what? The UNIX user/permission system, including the sticky bit used on /tmp, is supposed to protect local users against each other, but this is contingent on files created in /tmp using unique names (like what mktemp generates). There's very little else malicious people can do if the system is otherwise properly set up in a secure fashion, and this socket-in-/tmp thing sounds like a quite legitimate concern.

April 30, 2008

Re: wineserver socket file and DOS attacks

by Maarten Lankhorst

Hello Steven, 2008/4/30 Steven Elliott <selliott4(a)austin.rr.com>: > I have some concerns about the location of the socket file that > wineserver uses. Since by default the current location is in /tmp my > concern is that anyone can stop anyone else from using wine just by > creating a directory named /tmp/.wine-500. > > As far as I know the only risk is denial of service in nature since wine > seems to be smart enough to make sure the /tmp/.wine-500 is owned by the > user invoking the wine application: > > notepad > wineserver: /tmp/.wine-500 is not owned by you > > Previously the socket file was under ~/.wine. I found this which > briefly documents the change here: > http://www.winehq.org/site/docs/winedev-guide/x2584 > under section "7.3.2. The Wine server" it says: > > "In earlier versions of Wine the master socket mentioned above was > actually created in the configuration directory; either your home > directory's /wine subdirectory or wherever the WINEPREFIX environment > variable points. Since that might not be possible the socket is actually > created within the /tmp directory with a name that reflects the > configuration directory." > > /tmp/.wine-<user Id> is hard coded in libs/wine/config.c, so that aspect > of the socket file location is not configurable. > > Anyway, have alternatives such as the following been considered?: > > 1) Create the socket file in ~/.wine (or wherever WINEPREFIX points) > like wine used to if the user's home directory exists and is writable. > Use /tmp/.wine-<user Id> as a fallback. > > 2) Append some additional integer to /tmp/.wine-<user Id> that is > incremented if that directory already exists and is owned by someone > else. For example, if /tmp/.wine-500 already exists for user 500 but > is owned by someone else then both wineserver and the wine application > would append "-1" and then keep incrementing: > /tmp/.wine-500 > /tmp/.wine-500-1 > /tmp/.wine-500-2 The latter won't work, they could create the directory and then delete it after wineserver started. I don't think it is really a problem, by the time someone else can put that directory in /tmp chances are that they can do a lot more malicious things then just making Wine refuse to run. Cheers, Maarten.

April 30, 2008

Re: SOC 2008 Projects Announced

by Piotr Caban

Hi, I'll be working on msxml3.dll. I'm planning to implement SAX (Simple API for XML) and fix as much bugs related to this dll as I can. My main goal is to fix part of 8945 bug related to msxml. I'm from Poland. I'm a second year computer science student at University of Wroclaw. I was working on Wine's implementation of OleView two years ago (as SoC project). I'm really excited about this year project and looking forward for coding. Cheers, Piotr

April 30, 2008

Re: RFC: detecting wine drivers in the audio tests

by Juan Lang

> I think that is an excellent idea and I can see it being immediately > useful in rpcrt4, if not other areas. Indeed, I also think it's an excellent idea. The crypt32 chain tests are another good candidate for this approach. --Juan

April 30, 2008

Re: richedit: add tests for EM_FINDTEXT in 1.0 emulation, make them pass under Wine

by Alex Villacís Lasso

Alex Villacís Lasso escribió: > EM_FINDTEXT and EM_FINDTEXTEX have different rules for interpreting > ranges for 1.0 and 2.0 modes: > > In 1.0 emulation cpMin > cpMax is invalid and always fails. > In 1.0 emulation, search is always done between cpMin and cpMax, even > backwards search. > In 1.0 emulation, cpMax == -1 assumes FR_DOWN, even if not set. > > This goes a long way towards resolving richedit search problems in bug > #709. > > Changelog: > * Add tests for EM_FINDTEXT in 1.0 emulation, make them pass under Wine > My bad, it is bug #4144 that is being addressed with this patch. -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

April 30, 2008

Re: RFC: detecting wine drivers in the audio tests

by Robert Shearman

Francois Gouget wrote: > My idea is that > some platforms (e.g. Wine) could ask for stricter checks, by using > strict_wine a bit like they use todo_wine to request looser checks. > > So for instance you would do: > > strict_wine ok(expected_cond || buggy(this_is_a_bug), ...); > > Then on Windows the test would pass if either expected_cond is true or > if this_is_a_bug is true. The same would happen for other platforms that > this test runs on (e.g. ReactOS). > > However on Wine the strict_wine clause would cause buggy to always > return false. So on Wine this test would only succeed if expected_cond > is true. > > In addition to buggy I would propose a deprecated(cond) macro which > would behave exactly the same but document valid but deprecated Windows > behavior that we really don't want to reproduce. > I think that is an excellent idea and I can see it being immediately useful in rpcrt4, if not other areas. -- Rob Shearman

April 30, 2008

wineserver socket file and DOS attacks

by Steven Elliott

I have some concerns about the location of the socket file that wineserver uses. Since by default the current location is in /tmp my concern is that anyone can stop anyone else from using wine just by creating a directory named /tmp/.wine-500. As far as I know the only risk is denial of service in nature since wine seems to be smart enough to make sure the /tmp/.wine-500 is owned by the user invoking the wine application: > notepad wineserver: /tmp/.wine-500 is not owned by you Previously the socket file was under ~/.wine. I found this which briefly documents the change here: http://www.winehq.org/site/docs/winedev-guide/x2584 under section "7.3.2. The Wine server" it says: "In earlier versions of Wine the master socket mentioned above was actually created in the configuration directory; either your home directory's /wine subdirectory or wherever the WINEPREFIX environment variable points. Since that might not be possible the socket is actually created within the /tmp directory with a name that reflects the configuration directory." /tmp/.wine-<user Id> is hard coded in libs/wine/config.c, so that aspect of the socket file location is not configurable. Anyway, have alternatives such as the following been considered?: 1) Create the socket file in ~/.wine (or wherever WINEPREFIX points) like wine used to if the user's home directory exists and is writable. Use /tmp/.wine-<user Id> as a fallback. 2) Append some additional integer to /tmp/.wine-<user Id> that is incremented if that directory already exists and is owned by someone else. For example, if /tmp/.wine-500 already exists for user 500 but is owned by someone else then both wineserver and the wine application would append "-1" and then keep incrementing: /tmp/.wine-500 /tmp/.wine-500-1 /tmp/.wine-500-2 until they each found a directory owned by the current user (or until they are able to create one). Hopefully they would pick the same directory. I need to think more about how robust this would be. -- ----------------------------------------------------------------------- | Steven Elliott | selliott4(a)austin.rr.com | -----------------------------------------------------------------------

April 30, 2008

Re: RFC: detecting wine drivers in the audio tests

by Francois Gouget

On Wed, 30 Apr 2008, Robert Reif wrote: [...] > I am suppling a minimal patch to the alsa driver and a single wave test to > illustrate this concept. I hope this allows valid tests to remain in spite of > buggy windows drivers. I think it should be a more general winetest concept. My idea is that some platforms (e.g. Wine) could ask for stricter checks, by using strict_wine a bit like they use todo_wine to request looser checks. So for instance you would do: strict_wine ok(expected_cond || buggy(this_is_a_bug), ...); Then on Windows the test would pass if either expected_cond is true or if this_is_a_bug is true. The same would happen for other platforms that this test runs on (e.g. ReactOS). However on Wine the strict_wine clause would cause buggy to always return false. So on Wine this test would only succeed if expected_cond is true. In addition to buggy I would propose a deprecated(cond) macro which would behave exactly the same but document valid but deprecated Windows behavior that we really don't want to reproduce. Finally it would also be possible to use strict_wine before skip() calls to cause the skip() to fail if running on Wine (e.g. skipping due to a missing API should not be allowed when Wine is known to implement that API). Now we don't want to pepper these all over the tests (especially deprecated() and buggy()) so we'd need a strict policy for when to use these. I have attached a patch that implements an older incarnation of this idea (instead of deprecated/buggy there was just ok_strict). I hope to update it and submit it some day but in the meantime this can provide a starting point. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.

April 30, 2008

Re: [Resend 3] user32: Post the WM_KEY{DOWN|UP}messagewhenWM_IME_KEY{DOWN|UP} message is generated by IME.

by Dmitry Timoshkov

"ByeongSik Jeon" <bsjeon(a)hanmail.net> wrote: > I have attached new one. Looks good to me. -- Dmitry.

April 30, 2008

Re: RFC: detecting wine drivers in the audio tests

by Alexandre Julliard

Robert Reif <reif(a)earthlink.net> writes: > The returned result of some audio functions on windows may be > inconsistent because a driver may actually supply the returned value. > > This presents a problem for the wine regression tests because a buggy > driver may return an unexpected result which causes the test to fail. If the driver is buggy then it's OK for the test to fail. We don't need the tests to succeed on every single Windows machine out there, just on a reasonable sample. Either the failure is common and it means the test is useless and should be removed, or the failure is rare and we can live with it. We certainly can't rely on Wine drivers being identifiable, as this may break some apps. -- Alexandre Julliard julliard(a)winehq.org

April 30, 2008