Bug 803 - Security Bug: X11 Forwarding is more powerful than it needs to be.
Summary: Security Bug: X11 Forwarding is more powerful than it needs to be.
Status: CLOSED WORKSFORME
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 3.7.1p2
Hardware: All All
: P2 major
Assignee: OpenSSH Bugzilla mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-28 14:24 AEDT by Holger van Lengerich
Modified: 2004-04-14 12:24 AEST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Holger van Lengerich 2004-02-28 14:24:54 AEDT
Hi,

I just played a little bit with xauth and I thought I should drop a note in here:

Brief SSH X11 forwarding history:

1995 Tatu Ylönen releases ssh v1.0.0 including the X11 Forwarding feature

1996 Security extensions were defined for X11
     http://www.xfree86.org/~herrb/security.pdf

1997 Ulrich Flegel determines that X11 forwarding 
     ftp://ftp.dfn-cert.de/pub/docs/crypt/ssh-x11.ps.gz
      
     in response Alan Cox suggested that X11 Security Extensions may be used
     to limit the access of remote applications to the local X11 server

2004 X11 Forwarding is as dangerous as it was 1995:
     - keylogging (even though "secure keyboard" is used in 
       (xterm|ssh-agent|xscreensaver)
     - I was able to attach a X0vncserver process on an forwarded X-display 
       and got complete remote control.
     - screenshots of root window is possible through 'xwd' or ImageMagick's
       'import'

Time for a change isn't it? :)

I am able to implement Alan Cox's suggestion with 3 lines in a shell:
--- 8< ---
# transfer 'trusted' cookie to new file:
xauth extract - $DISPLAY | xauth -f $HOME/.sshXauthority merge -
# replace 'trusted' cookie with 'untrusted' cookie
xauth -f .sshXauthority generate $DISPLAY . untrusted
# tell applications where to get the untrusted cookie
export XAUTHORITY=$HOME/.sshXauthority
--- >8 ---

An attacker on the remote host is no more able to 
log keystrokes, taking screenshots or do remote control stuff.

So please consider:

-  mentioning the possibility of crippling access rights to the Xserver with 
   xauth in the manpage of ssh / ssh_config

or better:

-  modify SSH client to generate an untrusted cookie on its own and 
   using it for forwarded X11 requests. Of course there should be 
   possibility for choosing between 'trusted' or 'untrusted' X11 forwarding.
Comment 1 Holger van Lengerich 2004-02-28 14:38:12 AEDT
Ups. There is more I might tell:

The newly generated cookie is only used by the ssh client. So it will be very
soon invalidated if no other processes use this cookie. Perhaps if implemented a
new cookie should be obtained for every new X request or a timeout, which is
large enough may be associated with the cookie.

The first line "xauth extract ... | xauth -f .Xssh xauthority" is not necessary.
'xauth' is able to create a new Xauthority file right away. Originally I though
xauth needs a valid cookie to get a new one, but this wasn't the case. 

Securing X before ssh with X11 forwarding is done in 2 commands:

xauth -f $HOME/.sshXauthority generate $DISPLAY . untrusted timeout 3600 
export XAUTHORITY=$HOME/.sshXauthority

Comment 2 Darren Tucker 2004-02-28 16:40:36 AEDT
Err, you mean like this (from http://www.openssh.com/txt/release-3.8)?

Changes since OpenSSH 3.7.1:
============================ 
[...]
* ssh(1) now uses untrusted cookies for X11-Forwarding.
  Some X11 applications might need full access to the X11 server,
  see ForwardX11Trusted in ssh(1) and xauth(1) for more information.
Comment 3 Markus Friedl 2004-02-28 19:33:02 AEDT
holger, you forgot to mention that the default x11 security
policy has never changed and is not very much useful.
nothing uses it (except for openssh).
Comment 4 Markus Friedl 2004-02-28 19:36:04 AEDT
openssh defaults to untrusted cookies for about 5 months
Comment 5 Damien Miller 2004-04-14 12:24:20 AEST
Mass change of RESOLVED bugs to CLOSED