On 2016-01-23 06:50:51, Guido Günther wrote: > I had a look at RedHat's analysis[1] and at Squeeze, Wheezy and Jessie: > > * Squeeze and Wheezy don't run "xhost +si:localuser:`id -un`" from > xinit but we do so from Jessie on > * we have the security extension enabled > > however Debian uses ForwardX11Trused=yes so I wonder if we can safely > flag this as no-dsa needed for at least Wheezy and Squeeze since it does > not seem to affect the default configuration in any way?
So I have looked further into this. Besides the puzzle of setting up a X11-enabled squeeze VM (fun times), I was able to reproduce the issue well described in: https://thejh.net/written-stuff/openssh-6.8-xsecurity Indeed, by default, Debian is completely vulnerable *regardless* of the xhost configuration or timeout problems in ssh. This got me really confused because I couldn't see the "problem", because it's the default behavior in Debian, deliberately. To reproduce, the best is to use xdotool. We will use it to make the remote server (supposedly hostile) type in a local window, but it could also choose which window it would type in, sniff X11 traffic and more pretty bad stuff: $ ssh -X marcos xdotool type "this should not be working" thisshouldnotbeworking$ thisshouldnotbeworking So by default, in Debian, we set -X to behave like -Y. this works even if xhost access is disabled, so it's not specific to jessie and up. I tested it on Debian jessie (both client and server), but it should also fail for all Debian packages up to 3.8p1-2, shipped around the time sarge was released (!!). This was related to bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=237021 The reasoning for the setting is explained in the `README.Debian` file and is justified by saying "this has some problems in implementation - notably a very short timeout of the untrusted cookie - breaks large numbers of existing setups, and generally seems immature. The Debian package therefore sets the default for this option to "yes" (in ssh itself, rather than in ssh_config)." So to fix this, we'd have to remove that from patch 003a875a474100d250b6643270ef3874da6591d8 that lives in debian/patches/debian-config.patch: https://sources.debian.net/src/openssh/1:7.1p2-2/debian/patches/debian-config.patch/ It is somewhat a concern, in my opinion, that this is hardcoded in the source: why not just ship different config file defaults? Anyways, the immediate fix for this is at least to use ForwardX11Trusted=no everywhere. It remains to be tested if the xhost line needs to be removed to work around the timeout issues, but if so, this requires changes in wheezy and up. But all this work is useless if, by default, we bypass all those checks anyways. So this definitely need coordination with the openssh maintainers at this point, to at least confirm or infirm the "usability over security" decision that happened all that while ago. I personnally think the decision should be reverted, that ForwardX11Trusted should be set to the upstream "no" default. There's an entry in the OpenSSH FAQ exactly for that, and -Y to work around bad setups. It seems unreasonable to expose users to such a security issue just for the convenience of some setups that could easily be fixed. A.
