wineserver socket file and DOS attacks
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 | -----------------------------------------------------------------------
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.
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.
Hell Ove, 2008/4/30 Ove Kaaven <ovek(a)arcticnet.no>:
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. Wine checks ownership of the socket and directory, so race conditions aren't really a problem. This means that despite being put in a public directory there is no chance of a race condition. I don't see a security risk here, if someone is evil they could create that directory so wine wouldn't run, but that harm is only restricted to 'wine does not start'.
Cheers, Maarten.
Maarten Lankhorst skrev:
Wine checks ownership of the socket and directory, so race conditions aren't really a problem. This means that despite being put in a public directory there is no chance of a race condition. I don't see a security risk here, if someone is evil they could create that directory so wine wouldn't run, but that harm is only restricted to 'wine does not start'.
Which is exactly what the OP was concerned about.
On Thu, 2008-05-01 at 06:45 +0200, Ove Kaaven wrote:
Maarten Lankhorst skrev:
Wine checks ownership of the socket and directory, so race conditions aren't really a problem. This means that despite being put in a public directory there is no chance of a race condition. I don't see a security risk here, if someone is evil they could create that directory so wine wouldn't run, but that harm is only restricted to 'wine does not start'.
Which is exactly what the OP was concerned about.
You are correct that that is my concern. I just want to say a few additional things about this and then I'll leave it be since I think I've made my point. I've thought a little bit about how multiple directories could be used as a way working around the DOS attack (as I mentioned in my initial post). I think it is really hard to address every possible race condition (wineserver just starting up or shutting down as a new wine process is trying do decide which directory to use and or whether to start a new wineserver). I think Maarten touched on these race condition concerns with his "The latter won't work ..." email in this thread. To add to the confusion the /tmp directory on most Linux systems is subject to a cron job that deletes old files. I think the only perfectly robust way of doing this that isn't vulnerable to either DOS attacks or race conditions is have a permanent directory for each user that wants to use wine that is both owned by that user and is writable so that the socket file can be placed in it. At one time this was ~/.wine. So, what if the socket file was moved back under WINEPREFIX (defaults to ~/.wine) combined with the following requirements for users that don't have writable home directories the first time wine is run for that user: 1) Some new directory is created for the user. 2) The new writable directory is chown'd to the user. 3) WINEPREFIX is set to point to the directory. 4) wineperfixcreate is run. /etc/rc.d/init.d provides various examples of services that are run as users that don't have writable home directories but that do require a one time setup. For example, if "foo" is some service that uses wine then /etc/rc.d/init.d/foo would create /var/lib/foos-wine-dir if it didn't exist and then apply the above steps. You can also consider the SSH example where the ssh-agent process (analogous to wineserver) is started, some tempnam() like API is used to pick a random place for the socket file and then an environment variable (SSH_AUTH_SOCK) points to the socket file that must be inherited by each shell where SSH clients that want to talk to ssh-agent are used. But I've always thought having to deal with SSH_AUTH_SOCK was a pain (I know most distros set it for you when you are logged in at the console, which helps). Maybe I'm making some bad assumptions about why the socket file can't be placed in ~/.wine (that not all users have a writable home directory). I'm guessing based on the snippet from my original post that includes "Since that might not be possible" in reference to placing the socket file under ~/.wine. This made me curious what happens when ~/.wine is not writable. I did a "chattr +i" on the ~/.wine directory of an ordinary user in order to make every file immutable. Things pretty much work except wineserver complains when it exits that it can't write the registry changes to the *.reg files. And as one might expect the registry actually does not get updated. But other than that it kinda works. -- ----------------------------------------------------------------------- | Steven Elliott | selliott4(a)austin.rr.com | -----------------------------------------------------------------------
Steven Elliott <selliott4(a)austin.rr.com> writes:
Maybe I'm making some bad assumptions about why the socket file can't be placed in ~/.wine (that not all users have a writable home directory). I'm guessing based on the snippet from my original post that includes "Since that might not be possible" in reference to placing the socket file under ~/.wine.
No, the real problem with putting it under the home directory is that many setups have the home directory on a networked file system, but the socket needs to be local to the machine. I don't think the DoS is a big issue, but if it is for you it's pretty easy to have a script create the directories for all users at boot time. -- Alexandre Julliard julliard(a)winehq.org
On Mon, 2008-05-05 at 12:16 +0200, Alexandre Julliard wrote:
Steven Elliott <selliott4(a)austin.rr.com> writes:
Maybe I'm making some bad assumptions about why the socket file can't be placed in ~/.wine (that not all users have a writable home directory). I'm guessing based on the snippet from my original post that includes "Since that might not be possible" in reference to placing the socket file under ~/.wine.
No, the real problem with putting it under the home directory is that many setups have the home directory on a networked file system, but the socket needs to be local to the machine.
Do you happen to know in what cases there are issues with socket files and NFS directories? With a small test program I wrote I was able to work with a socket file on an NFS drive with both Fedora 8 and Red Hat AS 4: http://selliott.org/c/socket-file.cpp The test program just creates a socket file and listens on it in one instance and then connects to it in another. Maybe this works differently on non-Linux systems. Since my assumption was wrong about home directories being read-only then I'm curious if having a read-only WINEPREFIX directory is something that Wine supports assuming the WINEPREFIX directory is setup initially. As I mentioned in one of my other emails having a setup read-only WINEPREFIX directory pretty much works other than wineserver complaining that it can't write to the *.reg files when it exits. If having a writeable WINEPREFIX directory is a reasonable requirement then that suggests a solution that allows the socket file to be in /tmp and not vulnerable to DoS attacks - something like mkdtemp() could first securely create a unique directory in /tmp for the socket file and the location could be stored somewhere in WINEPREFIX. The location could be protected with a lock file in WINEPREFIX, so I think that would be pretty solid race condition and DoS wise.
I don't think the DoS is a big issue, but if it is for you it's pretty easy to have a script create the directories for all users at boot time.
It may not be a big issue. As Francois Gouget pointed out there seems to be other applications with similar socket files. So if you aren't concerned about this I understand. I imagine the upcoming 1.0 release has given you plenty of things to think about. That is a good suggestion about creating the directories on boot. Although it's tricky to do that when the users aren't local (NIS, or whatever) it's a good suggestion for most people. -- ----------------------------------------------------------------------- | Steven Elliott | selliott4(a)austin.rr.com | -----------------------------------------------------------------------
On Wed, 30 Apr 2008, Steven Elliott wrote:
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. [...]
In /tmp I see the following: .X0-lock .X11-unix/ fgouget/ gconfd-fgouget/ vmware-fgouget/ xmms_fgouget.0 So it seems like if there is a malicious user Wine will not be the only application that will be affected. So the question is: are all these apps susceptible to DoS or do they avoid DoS somehow? And if they prevent DoS, how and is that technique applicable to Wine? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.
On Mon, May 05, 2008 at 08:47:52AM +0200, Francois Gouget wrote:
On Wed, 30 Apr 2008, Steven Elliott wrote:
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. [...]
In /tmp I see the following:
.X0-lock .X11-unix/ fgouget/ gconfd-fgouget/ vmware-fgouget/ xmms_fgouget.0
So it seems like if there is a malicious user Wine will not be the only application that will be affected. So the question is: are all these apps susceptible to DoS or do they avoid DoS somehow? And if they prevent DoS, how and is that technique applicable to Wine?
For gconfd-* gconfd2 creates secondary directories if one is present (and checks if its there). .X11-unix/ is on suse created during install at least, so no problem. No idea about the others. Ciao, Marcus
On Mon, 2008-05-05 at 09:11 +0200, Marcus Meissner wrote:
On Mon, May 05, 2008 at 08:47:52AM +0200, Francois Gouget wrote:
In /tmp I see the following:
.X0-lock .X11-unix/ fgouget/ gconfd-fgouget/ vmware-fgouget/ xmms_fgouget.0
So it seems like if there is a malicious user Wine will not be the only application that will be affected. So the question is: are all these apps susceptible to DoS or do they avoid DoS somehow? And if they prevent DoS, how and is that technique applicable to Wine?
For gconfd-* gconfd2 creates secondary directories if one is present (and checks if its there).
.X11-unix/ is on suse created during install at least, so no problem.
No idea about the others.
Good question about other socket files. I wasn't able to get gconfd to create secondary files, so creating /tmp/gconfd-<user name> as another user broke gconf-editor for me. The .X* files should not be a problem if the X server is started when the system boots. But if the system boots up in text mode it's possible to stop the X server from being started manually (startx) by creating those directories and by putting bad files in them. -- ----------------------------------------------------------------------- | Steven Elliott | selliott4(a)austin.rr.com | -----------------------------------------------------------------------
participants (6)
-
Alexandre Julliard -
Francois Gouget -
Maarten Lankhorst -
Marcus Meissner -
Ove Kaaven -
Steven Elliott