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
runs.
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