wineserver socket file and DOS attacks

Steven Elliott selliott4 at austin.rr.com
Sat May 3 18:03:54 CDT 2008


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 at austin.rr.com     |
-----------------------------------------------------------------------





More information about the wine-devel mailing list