| 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? |
| 11 |
|
| 12 |
Anything that can connect to your X server can sniff your keyboard. |
| 13 |
Connecting to your X server requires: |
| 14 |
|
| 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. |
| 25 |
|
| 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. |
| 33 |
|
| 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. |
| 41 |
|
| 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. |
| 48 |
|
| 49 |
There are a couple of ways to protect yourself against this: |
| 50 |
|
| 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. |
| 68 |
|
| 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). |
| 73 |
|
| 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. |
| 80 |
|
| 81 |
-- |
| 82 |
Rich |
Archives