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