Is X vulnerable? - xinput and lack of app level isolation.
Hi, Typing this email now in thunderbird, and watching every single keystroke being logged from an open X terminal. How could I not known about this? I've only ever played with xev but the application window must have a least some focus (sloppy for mouse, selected for keyboard). Not only is xinput more useful than xev, but also more revealing to how vulnerable X can be to ones favorite and "trusted" X applications. I came across this while browsing unanswered questions in unix.stackexchange.com. (can't find it right now). Surely this is not true; "Any X window application can log all device inputs regardless of what X window application has focus" But thats not all that is possible. Anyhow I had to try it out for myself...
apt-get install xinput
xinput list
xinput test <id of device>
Xinput logs absolutely everything, anywhere. Regardless. Even an X application that opens as a different user (xauth). Do I trust any and all of the x applications I run? Thanks for the software, but I don't sorry. I'm not impressed by this at all and I'm ashamed I never new about it. I honestly thought there was some level of isolation, but there appears to be none. http://theinvisiblethings.blogspot.com.au/2011/04/linux-security-circus-on-g... A rather heavy alternative using xen virtualisation (apps run in different "zones") http://qubes-os.org Remember this has nothing to do with xauth or xhost. This is a feature of a single displayed instance of X. Login to your bank, paypal, su as root, whatever and hope xeyes isn't logging your keystokes or run xinput and watch it for yourself. Something to think about. Regards, Julian.
On Mon, 22 Oct 2012, Julian <tempura@internode.on.net> wrote:
Do I trust any and all of the x applications I run? Thanks for the software, but I don't sorry. I'm not impressed by this at all and I'm ashamed I never new about it. I honestly thought there was some level of isolation, but there appears to be none. [...] Remember this has nothing to do with xauth or xhost. This is a feature of a single displayed instance of X. Login to your bank, paypal, su as root, whatever and hope xeyes isn't logging your keystokes or run xinput and watch it for yourself.
Xephyr is the way to run untrusted X apps. They don't have to be run in a virtual machine, a different UID and/or SE Linux security context will do if you trust your kernel not to have local vulnerabilities. If you don't trust your kernel then by running a virtual machine you trust the VM system and the CPU both of which have the potential for bugs (and have had bugs in the past). You can use a separate PC for running untrusted apps, but then you have the issue of whether Xephyr is secure enough. Basically Xephyr is a program that creates a single window of a specified resolution on your X session and exports X access to that. So you can have a basic TWM setup (for a simple program) or a KDE or GNOME session in the virtual X environment. Below is one of the scripts I use for Xephyr. Note that it's using unencrypted X over the LAN. $ cat xe-basic #!/bin/sh IP=10.1.2.3 if [ "$XCMD" = "" ]; then XCMD=twm fi COOKIE=`mcookie` FILE=~/.XSauth-1 rm -f $FILE #echo $COOKIE HOST=$1 shift ssh $HOST "echo \"add $IP:1 . $COOKIE\" | xauth" echo "add :1 . $COOKIE" | xauth -f $FILE Xephyr :1 -auth $FILE -reset -terminate $* & #Xephyr :1 -auth $FILE $* & #DISPLAY=$IP:1 ssh $HOST twm ssh $HOST "DISPLAY=$IP:1 $XCMD" wait Here is one that tunnels all X over ssh: $ cat xe-enc-basic #!/bin/sh if [ "$XCMD" = "" ]; then XCMD=twm fi COOKIE=`mcookie` FILE=~/.XSauth-1 rm -f $FILE HOST=$1 shift ssh $HOST "echo \"add $IP:1 . $COOKIE\" | xauth" echo "add :1 . $COOKIE" | xauth -f $FILE echo "add :1 . $COOKIE" | xauth Xephyr :1 -auth $FILE -reset -terminate $* & DISPLAY=:1 ssh -C -Y $HOST "$XCMD" wait -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Julian writes:
Do I trust any and all of the x applications I run? Thanks for the software, but I don't sorry.
Don't run software you don't trust.
Xinput logs absolutely everything, anywhere. Regardless. Even an X application that opens as a different user (xauth).
Don't grant xauth privileges to users/hosts/networks you don't trust. https://en.wikipedia.org/wiki/X_Window_authorization By default a typical X session is set up to only allow a local user (and local root) to connect to the X server. Of course, if the attacker has physical access you are probably fucked.
Remember this has nothing to do with xauth or xhost. This is a feature of a single displayed instance of X. Login to your bank, paypal, su as root, whatever and hope xeyes isn't logging your keystokes or run xinput and watch it for yourself.
When I log into my bank, it is like this: xinit -- /usr/bin/midori bank.example.net That is, X starts, runs nothing but the browser, and when I quit the browser, X stops as well. So I am reasonably confident that information isn't leaking out -- unless a rogue process is already running as me and can therefore find the cookie file and connect to the server. Russel's idea of using nested X servers is probably equally sufficient. If, unlike me, you were already running X, I think you say xinit /usr/bin/X :1 -- ... I also run this every fifteen minutes: http://cyber.com.au/~twb/.bin/twb-privacy I would be interested to know how this issue compares to other common windowing systems. IIRC the only chord that cannot be intercepted by userland on Windows is Ctrl+Alt+Del...
"This is a feature of a single displayed instance of X." Running another instance of X would provide a level of isolation. That was obvious. From what I've read in the mailing list it appears that wayland addresses this issue. But yet to see wayland in action. Regards, Julian. On 23/10/12 08:54, Trent W. Buck wrote:
Julian writes:
Do I trust any and all of the x applications I run? Thanks for the software, but I don't sorry. Don't run software you don't trust.
Xinput logs absolutely everything, anywhere. Regardless. Even an X application that opens as a different user (xauth). Don't grant xauth privileges to users/hosts/networks you don't trust.
https://en.wikipedia.org/wiki/X_Window_authorization
By default a typical X session is set up to only allow a local user (and local root) to connect to the X server. Of course, if the attacker has physical access you are probably fucked.
Remember this has nothing to do with xauth or xhost. This is a feature of a single displayed instance of X. Login to your bank, paypal, su as root, whatever and hope xeyes isn't logging your keystokes or run xinput and watch it for yourself. When I log into my bank, it is like this:
xinit -- /usr/bin/midori bank.example.net
That is, X starts, runs nothing but the browser, and when I quit the browser, X stops as well. So I am reasonably confident that information isn't leaking out -- unless a rogue process is already running as me and can therefore find the cookie file and connect to the server.
Russel's idea of using nested X servers is probably equally sufficient. If, unlike me, you were already running X, I think you say
xinit /usr/bin/X :1 -- ...
I also run this every fifteen minutes: http://cyber.com.au/~twb/.bin/twb-privacy
I would be interested to know how this issue compares to other common windowing systems. IIRC the only chord that cannot be intercepted by userland on Windows is Ctrl+Alt+Del...
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
Julian <tempura@internode.on.net> wrote:
From what I've read in the mailing list it appears that wayland addresses this issue. But yet to see wayland in action.
This was all discussed comprehensively in an article on LWN recently. http://lwn.net/Articles/517375/
On 23 October 2012 08:54, Trent W. Buck <trentbuck@gmail.com> wrote:
Don't grant xauth privileges to users/hosts/networks you don't trust.
Fortunately most people don't run "xhost +" any more (use to be common practise when I was at Monash University). -- Brian May <brian@microcomaustralia.com.au>
Brian May writes:
On 23 October 2012 08:54, Trent W. Buck <trentbuck@gmail.com> wrote:
Don't grant xauth privileges to users/hosts/networks you don't trust.
Fortunately most people don't run "xhost +" any more (use to be common practise when I was at Monash University).
ssh still defaults to -X in a lot of places, though. (Granted, that's not nearly as bad.)
On Wed, 24 Oct 2012, Jason White wrote:
Trent W. Buck <trentbuck@gmail.com> wrote:
ssh still defaults to -X in a lot of places, though. (Granted, that's not nearly as bad.)
Those places include the default Debian configuration (unless this has been changed since mine was installed).
You mean -Y now actually is usefully working for something in the real world now? -- Tim Connors
Tim Connors <tconnors@rather.puzzling.org> writes:
On Wed, 24 Oct 2012, Jason White wrote:
Trent W. Buck <trentbuck@gmail.com> wrote:
ssh still defaults to -X in a lot of places, though. (Granted, that's not nearly as bad.)
Those places include the default Debian configuration (unless this has been changed since mine was installed).
You mean -Y now actually is usefully working for something in the real world now?
Er, please note that -Y is *less secure* than -X. It's "trusted X11 forwarding" as in "trust the network to not be full of bastards". Earlier, I was referring to -X being on by default by contrast to only turning it on when you are explicitly want to forward X.
On Wed, 31 Oct 2012, Trent W. Buck wrote:
Tim Connors <tconnors@rather.puzzling.org> writes:
On Wed, 24 Oct 2012, Jason White wrote:
Trent W. Buck <trentbuck@gmail.com> wrote:
ssh still defaults to -X in a lot of places, though. (Granted, that's not nearly as bad.)
Those places include the default Debian configuration (unless this has been changed since mine was installed).
You mean -Y now actually is usefully working for something in the real world now?
Er, please note that -Y is *less secure* than -X. It's "trusted X11 forwarding" as in "trust the network to not be full of bastards".
Woops, turns out I haven't read the manpage recently. Why would you want that? -- Tim Connors
participants (6)
-
Brian May -
Jason White -
Julian -
Russell Coker -
Tim Connors -
trentbuck＠gmail.com