[Novalug] SSH security - agent + x forwarding

[Jason Kohles]

I don't get to choose to not login to untrusted machines.  ;)

Keep in mind that 'untrusted' doesn't necessarily mean 'dangerous' or
'sketchy'.  In my case I log in to a lot of Palantir machines that are
managed by other groups within Palantir.  Even though I trust my
coworkers, I consider most of those to be untrusted machines, because I
don't necessarily know exactly who has root access to them, and they may
not be in our datacenter, so I don't necessarily know who exactly has
physical access to them either.

The way X works is that you are running an X server locally on your
machine.  X clients connect to that server and interact with it to cause
their windows to be drawn on the display.  Any X client can connect to
your X server and interact with it assuming that it can reach the network
port where the server is listening (which may be affected by firewalls or
NAT) and assuming that either the server is configured to accept all
connections from that client, or the client has a 'magic cookie' that
allows it to connect.

When you run ssh with X forwarding, the SSH session sets up a listening
port on the remote machine that forwards through the ssh tunnel back to
the actual X port on your local machine, sets your remote $DISPLAY
variable appropriately so that X clients will use that port to connect,
and copies the appropriate 'magic cookie' information to the remote
machine.

So when you login to a remote machine with X forwarding enabled, anyone
who is logged into that machine can have complete and unrestricted access
to your X session, as long as they can access both the port that is doing
the forwarding, and your 'magic cookies' which are stored in
~/.Xauthority.  The X forwarding stuff in ssh makes sure that your
.Xauthority is only readable by you, which prevents the regular users on
the machine from accessing it, but anyone with root access can still read
that file and control your Xsession.


If you have access to a linux host that you can login to as two different
users, you can easily demonstrate this.  Assuming your local machine is
named 'local', and you can login to a remote machine named 'remote' as
both 'user' and 'root', then try this:

# Login to the remote machine as user, with X forwarding enabled
user at local> ssh -X user at remote

# Find out what display the forwarded connection is using
user at remote> echo $DISPLAY
localhost:10.0

# In a separate window, login to the remote machine again,
# but this time as root, and with X forwarding *disabled*
user at local> ssh -x root at remote

# Note that root does not have a $DISPLAY set, so no x-forwarding..
root at remote> echo $DISPLAY

# Set the $DISPLAY for root to match the one for user
root at remote> export DISPLAY=localhost:10.0

# Try to run an X application as root
root at remote> xeyes
Error: Can't open display: localhost:10.0

You can't run xeyes as root because you don't have the magic cookie.


However, in the window where you logged in as user you will also
(probably) see errors indicating that X11 connections were rejected
because of that missing cookie:

user at remote> X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.


# So, as root set the $XAUTHORITY variable to point at the users
.Xauthority 

root at remote> export XAUTHORITY=/home/user/.Xauthority

# Now try again..
root at remote> xeyes

Success!  YOu now have an xeyes process running as root displaying back to
your user session.



This is also where the difference between the ssh options -X and -Y comes
into play.  The -X mode is more secure, it allows the remote client to
draw windows to your display, but doesn't allow it to do things like
monitor your keyboard or screenshot your display.  The -Y option treats
the remote client exactly the same as a local client, giving it complete
access to your session.  So generally speaking you want -X rather than -Y,
but using -X requires that the clients support the XSECURITY extension.
If you need to run clients that don't know anything about XSECURITY, then
you have to use -Y in order for those clients to work..



-- 
Jason Kohles
Palantir Technologies | UNIX Systems Engineer
jkohles at palantir.com  | 703.957.5784







On 3/19/12 8:54 PM, "Nick Danger" <nick at hackermonkey.com> wrote:

I don't even log into untrusted machines, solves the whole issue ;-)

On 03/19/2012 02:38 PM, Jason Kohles wrote:
> It's a similar situation with X forwarding, it isn't just about
>forwarding
> X output, if you login to an untrusted machine with X forwarding enabled
> then someone with root access to that machine can also watch your
>display,
> monitor your keystrokes, and take control of your X session.

Thats what I don't understand. If I log into machine X, and launch
firefox, I understand they can monitor my firefox session but how does
someone take over the whole X session on the client? Is this more of
something with X versus just the fact I am forwarding at all?


>
> With a socks proxy you can mitigate some of the risk by using end-to-end
> encryption on top of the socks connection.  So, in your example the admin
> of shell.x.com could watch your http traffic, but you could avoid that by
> using https..
>
As in, why cant someone take over my entire X session here? Or can they?
I guess I don't completely understand all that is happening in an X
forwarding session.

Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4634 bytes
Desc: not available
Url : http://calypso.tux.org/pipermail/novalug/attachments/20120320/6be2c336/attachment.bin