Gentoo Archives: gentoo-user

From: n952162 <n952162@×××.de>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] is the X11 Security extension required for xauth?
Date: Tue, 24 Dec 2019 19:08:51
In Reply to: Re: [gentoo-user] is the X11 Security extension required for xauth? by Rich Freeman
1 Thank you for the overview.
3 What are the downsides of the security extension, that it's not enabled
4 by default.   If performance, do you have any idea what the hit is
5 (before I start re-emerging)?
8 On 12/23/19 23:31, Rich Freeman wrote:
9 > On Mon, Dec 23, 2019 at 1:15 AM Adam Carter <adamcarter3@×××××.com> wrote:
10 >>> The difference between -X and -Y is in providing a layer of security
11 >>> so that remote clients can't play games like keyboard sniffing with
12 >>> your local X server.
13 >>
14 >> I had conflated those extra checks with .Xauthority.
15 >>
16 >> 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?
17 > Anything that can connect to your X server can sniff your keyboard.
18 > Connecting to your X server requires:
19 >
20 > 1. A network/socket connection (which usually means being on the same
21 > machine/LAN, or having access to the other side of the ssh tunnel
22 > which probably means being on the remote ssh server).
23 > 2. Authenticating with the X server, typically using a cookie from an
24 > .Xauthority file, a copy of which is in your home directory when you
25 > log in using a display manager, and another copy will be created in
26 > your home directory on the remote ssh server when you connect using
27 > ssh X11 forwarding. There are non-cookie methods of authenticating
28 > with X11 I think but I'm less familiar with them, and they're much
29 > less common.
30 >
31 > So, anything with access to your home directory on your X server (ie
32 > your desktop), or on the remote ssh server, which would generally
33 > include root on both hosts, can connect to your X server. Any process
34 > which does so can sniff your keyboard/mouse input (and I think screen
35 > as well) for the most part. X11 does NOT restrict client applications
36 > to only receiving keystrokes destined for its own windows. That has
37 > been a very longstanding security weakness in X11.
38 >
39 > In the case of local processes it isn't as much of a hole, because in
40 > most cases the only processes that can talk to your X server can also
41 > read all your data from your home directory, and attach to your own
42 > processes to read their memory/etc. Unless you're using some kind of
43 > application containerization layer (not common yet), Linux doesn't
44 > provide much isolation between processes running under the same UID if
45 > one is malicious.
46 >
47 > However, when you're connecting to a remote server with X11
48 > forwarding, you now are giving access to your keyboard/mouse/etc to
49 > processes on that remote host, which otherwise would NOT be able to
50 > access your local host. If you remotely admin servers/etc you
51 > probably aren't intending to give the owners of those servers the
52 > ability to spy on your desktop.
53 >
54 > There are a couple of ways to protect yourself against this:
55 >
56 > 1. ssh -X, if you have the security extension in your X server, will
57 > block these sorts of attacks at the X11 level. X11 API calls that try
58 > to intercept this sort of data will fail (I don't know the gory
59 > details).
60 > 2. Some applications are hardened against these attacks by taking
61 > exclusive access of input (similar to a modal dialog):
62 > a. The X11 implementations of app-crypt/pinentry grab exclusive
63 > input access when they run. This is why you should ALWAYS use the X11
64 > version of these programs for ssh/gpg agent passphrase entry, and not
65 > just have the agent read input in an xterm/etc. The X11 application
66 > will block key sniffing via hostile X clients.
67 > b. Some xterm implementations have buried in their menus a secure
68 > mode option, which while selected grabs exclusive input access. It is
69 > intended to be used anytime you enter a password or other sensitive
70 > data, but must be manually turned on/off when needed. You can't just
71 > leave it on all the time because then no other applications will be
72 > able to respond to keyboard input.
73 >
74 > These issues date WAY back to the beginning of X11. I remember first
75 > reading about them in the 90s in a tip to avoid giving untrusted hosts
76 > the ability to run X clients (back in an era where things like X
77 > terminals were more common).
78 >
79 > Apologies if I got any details wrong here, but I'm pretty sure this is
80 > the gist of how the issue works. How big an issue really depends on
81 > how you use X11 forwarding in ssh. If you're the sort of person who
82 > remotely admins client servers via ssh you probably should avoid using
83 > ssh -Y though. While I've never heard of this being exploited in
84 > recent times, it is definitely a risk.
85 >