Source-Changes archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: basesrc
On Mon, Jun 18, 2001 at 11:21:36AM -0400, Perry Metzger wrote:
>
> Luke Mewburn <lukem%netbsd.org@localhost> writes:
> > Module Name: basesrc
> > Committed By: lukem
> > Date: Mon Jun 18 10:26:33 UTC 2001
> >
> > Modified Files:
> > basesrc/crypto/dist/ssh: session.c sshd.8
> >
> > Log Message:
> > If UseLogin is enabled, disable X11Forwarding (since xauth passing doesn't
> > work in this case, so X11Forwarding is effectively useless). Document this.
> > Resolves my pr [security/13172].
>
> This *should* work. In fact, UseLogin *should* be the way we generally
> run a program like ssh -- we use login as the interface on telnet and
> rlogin to prevent duplication of code (and bugs). Documenting it as
> broken doesn't strike me as being reasonable -- we should fix it
> instead.
>
> Can we reopen the issue?
No, I don't think so.
Have a look at the way that X11Forwarding is implemented. It effectively
comprises of:
* creating a tunnel for the X traffic (ssh & sshd)
* creating a one-time $DISPLAY (e.g, "server:55") and and
appropriate xauth cookie for that session (ssh)
* passing this new $DISPLAY and cookie (ssh to remote sshd to deal with)
Our login(1) can't handle the cookie (or the DISPLAY, unless it's in the
environment before-hand). Hacking login(1) to support this cookie
munging is something that I strongly object to.
Any other work-around that could be done in sshd, such as passing the real
$DISPLAY (e.g, "client:0") instead of the fake $DISPLAY (e.g, "server:55")
defeats the purpose of using ssh for this traffic to ensure integrity and
confidentiality of the X11 traffic, as well as protecting your X server
from cookie abuse from the remote site after you disconnect.
BTW: The `original' ssh 1.2.x client has the same problem WRT UseLogin.
Home |
Main Index |
Thread Index |
Old Index