[Bug 1926] New: use Xephyr for "secure" X-forwarding

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=1926

             Bug #: 1926
           Summary: use Xephyr for "secure" X-forwarding
    Classification: Unclassified
           Product: Portable OpenSSH
           Version: 5.8p1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: ssh
        AssignedTo: unassigned-bugs at mindrot.org
        ReportedBy: calestyo at scientia.net


Hi.

I'm not sure whether I really understood the details of Xephyr and how
it interacts with the host X server correctly, but to me it seems that
this runs as a separate X server, not having access to anything of the
host X server.

X11Forwarding is considered insecure, cause a malicious remote host
could tamper with the client's host X server, right?
Therefore I basically never use it.


Why not adding a new feature that does about the following (let's call
it -SX for the moment).

If the user does something like ssh -SX remote.host, X-forwarind is
(completely secured via SSH tunnels) enabled and DISPLAY is set, but
not to the client's host X server, but to a freshly invoked Xephyr
instance started by ssh.

As far as I understand - but experts should probably confirm this - one
would then have a separate Window (from Xephyr) and only the contents/X
server of THIS very window can be attacked by the remote host.
But this shouldn't be a great deal as it's anyway only the remote
host's stuff that runs in there.
Perhaps one could even add some functionally to Xephyr that marks such
a window with big fat red borders (or whatever) to hint the user that
this is untrusted and that he shouldn't enter his password there ;).

Of course it must be secured, that the Xephys server and the tunnels
are killed once the connection is closed (but I guess this would work
more or less of out the box anyway).

Of course, for every connection, new Xephyr servers would have to be
started, otherwise, different remote hosts could attack the contents of
each other[1].


Features one could think of:
- an ssh_config option to specifiy the parameters to Xephyr. So one
could e.g. per host, set how big the Xephyr windows should be.
- an option to minimise the Xephyr window in the beginning (would sound
useful to me, especially if one does a plain ssh login, and not
starting a command).
- an option that different ssh connections to the __same__
host/address-literal are allowed to use the same Xephyr server (in
contrast to [1]).

Not sure whether it's technically possible to add functionality that
the Xephyr server is started only on demand, e.g. when the first remote
program tries to open a connection.
If so that would be very nice, but in this case it would REALLY be
important to prevent focus/input stealing by suddenly started Xephyr
windows (while e.g. the user just enters a password on the safe host X
server). Not sure whether starting the Xephyr window minimised is
enough protection here.


Cheers,
Chris.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.