[PATCH] tcp-wrappers support extended to x11 forwards

[Ed Phillips]

On Fri, 30 Nov 2001, Osmo Paananen wrote:

> Date: Fri, 30 Nov 2001 09:16:13 +0200
> From: Osmo Paananen <odie at rotta.media.sonera.net>
> To: Ed Phillips <ed at UDel.Edu>
> Cc: Kevin Steves <stevesk at pobox.com>, openssh-unix-dev at mindrot.org
> Subject: Re: [PATCH] tcp-wrappers support extended to x11 forwards
>
> > I you login to SystemB with X forwarding enabled to SystemA, then an
> > attacker gets your fake cookie on SystemB, how do you propose to prevent
> > him from running X programs and displaying on SystemA - even with the
> > proposed X wrapper support?  It doesn't seem stoppable, since you've
> > enable forwarding for SystemB-to-SystemA, the attacker is logged into
> > SystemB, and has your fake cookie...
>
> ACL won't protect me in that case.
>
> But without ACL the attack can come from host C which is not related to
> A or B.  The attacker doesn't have the fake cookie, but he may guess it
> (by trying several times).  I don't know how possible values there are for
> the fake cookie. My guess is that there is a lot of them. That is why
> this is not a big security hole.

Okay... I see now.  It's a little scary that even with a valid "fake"
cookie that has somehow been stolen and put on SystemC, that a hacker on
SystemC could display X progrms on SystemA.  I would have guessed that
unless you configured ssh/sshd to explicitly allow this kind of X
forwarding, it wouldn't work - but I just tried it and it works fine.  I
guess this is why there has been talk lately about the "fake" X server
port being bound to localhost explicity or not (at least I think that's
what they were talking about)...

> Sure, the attack will be noisy and time consuming.
>
> But still the hole is there. And there is no reason for it to be there.

I agree.  There are already enough "gotchas" with supporting X
forwarding, without having to create more with the "fake" X server socket
itself.  It'd be nice if there were a way to "wrapper" the "fake" X server
socket to not allow this... which I think is exactly your suggestion - now
that I understand a little more. ;-)

On a side note, I recently reported a bug (and received no response)
that is relevent to the above.  If a hacker were actually trying to use
random cookies from SystemC to diplay on SystemA through SystemB... there
is a bug in ssh/sshd were they hang around instead of exiting when you log
out - and in this scenario, the bug allows the hacker to keep trying
cookies forever or until you explicitly kill ssh/sshd.  The bug itself
seems to cause ssh/sshd to hang instead of exiting.  I also submitted the
exact details on how to reproduce the bug.  That was weeks ago...

Regards,

	Ed

Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082
Systems Programmer III, Network and Systems Services
finger -l ed at polycut.nss.udel.edu for PGP public key