X11forwarding yes: how to debug/setup after xauth fix

Michael Felt michael at felt.demon.nl
Wed Oct 4 20:28:29 AEDT 2017

On 04/10/2017 11:07, Michael Felt wrote:
> I know that there is a security-fix starting with openssh-7.2 
> (https://www.openssh.com/security.html, March 9, 2016) - and when I 
> load any version of openssh prior to Openssh-7.2 I get the expected 
> X11 behavior over an ssh(d) X11forwarding tunnel.
> So, what should I be looking at on my server or client-side. Is there 
> a different setting I should be using? I am still using the "putty" 
> setting of: MIT-Magic-Cookie-1. (I'll test, in a moment using 
> XDM-Authorization-1). 
Did not help.
> However, the hint I am hoping for is the flag to set for sshd (e.g., 
> -ddddd) and what debug string - to see if X11forwarding is attempted, 
> and if so, why it is rejected by the sshd.

Looking further: How can I see what is failing? Can I add a character to 
the whitelist (once I know what is rejected)?

imho: the cure may be worse than the illness if this means my X11 
sessions are either "clear" or impossible - as they are not in the SSH 
(encrypted) tunnel.

 From http://www.openssh.com/txt/x11fwd.adv

4. Details

         As part of establishing an X11 forwarding session, sshd(8)
	accepts an X11 authentication credential from the client.
	This credential is supplied to the xauth(1) utility to
	establish it for X11 applications that the user subsequently

	The contents of the credential's components (authentication
	scheme and credential data) were not sanitised to exclude
	meta-characters such as newlines. An attacker could
	therefore supply a credential that injected commands to
	xauth(1). The attacker could then use a number of xauth
	commands to read or overwrite arbitrary files subject to
	file permissions, connect to local ports or perform attacks
	on xauth(1) itself.

	OpenSSH 7.2p2 implements a whitelist of characters that
	are permitted to appear in X11 authentication credentials.

More information about the openssh-unix-dev mailing list