Re: [gentoo-user] is the X11 Security extension required for xauth?

[n952162]

Thank you for the overview.

What are the downsides of the security extension, that it's not enabled
by default.   If performance, do you have any idea what the hit is
(before I start re-emerging)?


On 12/23/19 23:31, Rich Freeman wrote:
> On Mon, Dec 23, 2019 at 1:15 AM Adam Carter <adamcarter3@×××××.com> wrote:
>>> The difference between -X and -Y is in providing a layer of security
>>> so that remote clients can't play games like keyboard sniffing with
>>> your local X server.
>>
>> I had conflated those extra checks with .Xauthority.
>>
>> How would the keyboard sniffing attack work? Since everything over the network is made confidential by ssh, i'm guessing the attack would be by a local user on the ssh client/X server box somehow?
> Anything that can connect to your X server can sniff your keyboard.
> Connecting to your X server requires:
>
> 1.  A network/socket connection (which usually means being on the same
> machine/LAN, or having access to the other side of the ssh tunnel
> which probably means being on the remote ssh server).
> 2.  Authenticating with the X server, typically using a cookie from an
> .Xauthority file, a copy of which is in your home directory when you
> log in using a display manager, and another copy will be created in
> your home directory on the remote ssh server when you connect using
> ssh X11 forwarding.  There are non-cookie methods of authenticating
> with X11 I think but I'm less familiar with them, and they're much
> less common.
>
> So, anything with access to your home directory on your X server (ie
> your desktop), or on the remote ssh server, which would generally
> include root on both hosts, can connect to your X server.  Any process
> which does so can sniff your keyboard/mouse input (and I think screen
> as well) for the most part.  X11 does NOT restrict client applications
> to only receiving keystrokes destined for its own windows.  That has
> been a very longstanding security weakness in X11.
>
> In the case of local processes it isn't as much of a hole, because in
> most cases the only processes that can talk to your X server can also
> read all your data from your home directory, and attach to your own
> processes to read their memory/etc.  Unless you're using some kind of
> application containerization layer (not common yet), Linux doesn't
> provide much isolation between processes running under the same UID if
> one is malicious.
>
> However, when you're connecting to a remote server with X11
> forwarding, you now are giving access to your keyboard/mouse/etc to
> processes on that remote host, which otherwise would NOT be able to
> access your local host.  If you remotely admin servers/etc you
> probably aren't intending to give the owners of those servers the
> ability to spy on your desktop.
>
> There are a couple of ways to protect yourself against this:
>
> 1.  ssh -X, if you have the security extension in your X server, will
> block these sorts of attacks at the X11 level.  X11 API calls that try
> to intercept this sort of data will fail (I don't know the gory
> details).
> 2.  Some applications are hardened against these attacks by taking
> exclusive access of input  (similar to a modal dialog):
>     a.  The X11 implementations of app-crypt/pinentry grab exclusive
> input access when they run.  This is why you should ALWAYS use the X11
> version of these programs for ssh/gpg agent passphrase entry, and not
> just have the agent read input in an xterm/etc.  The X11 application
> will block key sniffing via hostile X clients.
>     b.  Some xterm implementations have buried in their menus a secure
> mode option, which while selected grabs exclusive input access.  It is
> intended to be used anytime you enter a password or other sensitive
> data, but must be manually turned on/off when needed.  You can't just
> leave it on all the time because then no other applications will be
> able to respond to keyboard input.
>
> These issues date WAY back to the beginning of X11.  I remember first
> reading about them in the 90s in a tip to avoid giving untrusted hosts
> the ability to run X clients (back in an era where things like X
> terminals were more common).
>
> Apologies if I got any details wrong here, but I'm pretty sure this is
> the gist of how the issue works.  How big an issue really depends on
> how you use X11 forwarding in ssh.  If you're the sort of person who
> remotely admins client servers via ssh you probably should avoid using
> ssh -Y though.  While I've never heard of this being exploited in
> recent times, it is definitely a risk.
>