Security issues with abstract namespace sockets

[Adam Jackson]

On Wed, 2011-01-05 at 13:38 -0500, Matt McCutchen wrote:
> On Wed, 2011-01-05 at 11:12 -0500, Adam Jackson wrote:
> > The deeper problem is that clients authenticate themselves to the
> > server, but then simply trust that the server is the server they were
> > hoping for.  If you don't have a process tree relationship (like the gdm
> > +displayfd case) then you have to go all the way to something like
> > Kerberos for that kind of bidirectional auth.
> 
> Not quite: you can use the xauth cookie as a pre-shared key.

That doesn't work.  If you're trying to spoof the X server then you
write an X server that simply accepts whatever auth cookie you give it.
There's no way, once you've connected to X, to ask what cookies it
accepts.  (Because different auth cookies can have different security
levels, so you don't want to disclose to a less-trusted level the cookie
of a more-trusted level.)  The only way you can know what cookies it
accepts is if you started it yourself; and if you did that, you have a
process tree relationship.

> > and indeed, has _more_ DoS
> > conditions than abstract sockets since they don't get garbage-collected
> > on system crash
> 
> They do if you use a tmpfs (e.g., /var/run with systemd), but in any
> event it's easy enough to unlink the socket or try another name.

Your attacker wants to spoof a service.  They've created a socket on the
name you want, and now you want to unlink it and make your own.  Why do
you think they can't notice the unlink and recreate the socket?  Thus
making it a race you might win sometimes, depending on how the scheduler
is feeling on any given day.

> The
> more significant DoS condition is another user taking the name you want,
> which can happen in the abstract namespace but not in a directory only
> you can write.

I don't have any of those.  If the X server is running as root (like in
the gdm case) then I can put the socket wherever I want.  If it's Xvfb,
then where do I put this directory?  $HOME ?  Nope, might not be
there.  /tmp/$USER ?  Won't work if someone else mkdir'd /tmp/ajax
before I did.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110105/be10ee26/attachment.bin