[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: ssh X forwarding change in FC3

P draigBrady com wrote on Thursday 06 January 2005 09:47:
> The FC3 release notes say:
> "The behavior of ssh clients that are invoked with the -X flag has
> changed. In OpenSSH 3.8 and later, X11 forwarding is performed in a
> way that applications run as untrusted clients by default.
> Previously, X11 forwarding was performed so that applications always
> ran as trusted clients. Some applications may not function properly
> when run as untrusted clients. To forward X11 so that applications
> are run as trusted clients, invoke ssh with the -Y flag instead of
> the -X flag, or set ForwardX11Trusted in the ~/.ssh/config file."
> See also:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141515
> Essentially what this means is that most X applications will
> break if forwarded back to a FC3 system with default config.
> Now it wouldn't be so bad if they just wouldn't work.
> They break in subtle ways usually related to mouse events.
> This is just silly IMHO and will cause no end of hassles
> for users trying to figure out what's going on and
> also be a waste of time for developers of those X apps
> who will receive bogus bug reports.
> So can we change the upstream default back to what it used to be?

It's not just silly -- it reduces the size of a security hole.  If X 
apps can be fixed to deal with running as an untrusted X client, then 
they should be fixed.  If a given X app can't be run untrusted, I don't 
know what to suggest.

Here's the security problem with running as a trusted client.  If I ssh 
-Y (or ssh with old defaults) into a machine where someone else can use 
my xauth cookie (e.g. the remote machine has a compromise of my account 
or of root), then the compromiser can read not only my keystrokes on 
the remote machine, but my keystrokes on my desktop.  That's bad.

If I tell ssh to treat tunneled X clients as untrusted (the new default 
behavior), on the other hand, then remote intruders cannot read my 
local, trusted-client keystrokes.  They can still read my keystrokes on 
other untrusted clients (e.g. an xterm on a different remote 
ssh-accessed machine), but that's not quite as bad as the old default.

X only has this untrusted/trusted distinction; it probably really needs 
a widely-used, more featureful security model.

All this is *my understanding* of X security, based on reading rather 
than direct testing; if I got something wrong, please correct me. :)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]