Gentoo Archives: gentoo-user

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


Subject Author
Re: [gentoo-user] is the X11 Security extension required for xauth? n952162 <n952162@×××.de>