Products > Security

Xorg security flaw (by design, not a bug)

(1/6) > >>

RoGeorge:
I was building an Arch Linux and not sure what Desktop Environment to choose, so having some time to spare, gave it a little read about Xorg and Wayland architectures, and surprise:  Xorg has no isolation between windows.

For example:

--- Code: ---    ~$ # demo for the possibility of a keylogger without elevated rights ([url]https://www.secjuice.com/wayland-vs-xorg/[/url])
    ~$ # In any Linux with an Xorg based GUI, open a terminal window, let's call it T1, and type:

    ~$ xinput list
    ⎡ Virtual core pointer                          id=2    [master pointer  (3)]
    ⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
    ⎜   ↳ A4TECH USB Device Consumer Control        id=12   [slave  pointer  (2)]
    ⎜   ↳ A4TECH USB Device                         id=13   [slave  pointer  (2)]
    ⎜   ↳ Logitech USB RECEIVER                     id=14   [slave  pointer  (2)]
    ⎜   ↳ Razer Razer Diamondback Optical Mouse     id=15   [slave  pointer  (2)]
    ⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
        ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
        ↳ Power Button                              id=6    [slave  keyboard (3)]
        ↳ Video Bus                                 id=7    [slave  keyboard (3)]
        ↳ Power Button                              id=8    [slave  keyboard (3)]
        ↳ Sleep Button                              id=9    [slave  keyboard (3)]
        ↳ A4TECH USB Device Keyboard                id=10   [slave  keyboard (3)]
        ↳ A4TECH USB Device System Control          id=11   [slave  keyboard (3)]
        ↳ AT Translated Set 2 keyboard              id=16   [slave  keyboard (3)]
        ↳ A4TECH USB Device Consumer Control        id=17   [slave  keyboard (3)]

    ~$ # Keyboard id here is 16, now read all the keys pressed, including those from OTHER windows
   
    ~$ xinput test 16
   
    ~$ # Now, open another terminal, T2, and in T2 type a 'sudo ls' command.
    ~$ # Note theat ALL keys pressed anywhere will be listed in T1,
    ~$ #   including the password you typed for the sudo command in the T2 window!
   
    ~$ # Wayland doesn't have this design flaw.

--- End code ---

This means any window in Xorg could be a keylogger, and could spy for passwords or other sensitive data typed in any other window.   :o

Any Linux distro running Xorg is vulnerable to such a trojan, and Xorg is the most widespreaded window server (i.e. Ubuntu comes with Xorg by default).

I don't get it, why the X server was designed like that, and how that nobody complains about such a vulnerability?   :-//

madires:
The X Window System is old and back then security wasn't a design goal. It has also a ton of features most users don't even know they exist. Adding up-to-date security will break them and compatibility with applications. Therefore we will have to wait for a successor to solve all the security issues.

mrflibble:
There are some mitigations, but the design is from a previous millenium for sure.

For an example of such mitigation, see for example this snippet from the xterm man page:

--- Quote ---SECURITY
       X environments differ in their security consciousness.

       · Most servers, run under xdm, are capable of using a “magic cookie” authorization scheme that can provide a reasonable level of security for many people.  If your server is only using a host-based
         mechanism to control access to the server (see xhost(1)), then if you enable access for a host and other users are also permitted to run clients on that same host, it is possible that someone can
         run an application which uses the basic services of the X protocol to snoop on your activities, potentially capturing a transcript of everything you type at the keyboard.

       · Any process which has access to your X display can manipulate it in ways that you might not anticipate, even redirecting your keyboard to itself and sending events to your application's windows.
         This is true even with the “magic cookie” authorization scheme.  While the allowSendEvents provides some protection against rogue applications tampering with your programs, guarding against a
         snooper is harder.

       · The X input extension for instance allows an application to bypass all of the other (limited) authorization and security features, including the GrabKeyboard protocol.

       · The possibility of an application spying on your keystrokes is of particular concern when you want to type in a password or other sensitive data.  The best solution to this problem is to use a
         better authorization mechanism than is provided by X.

       Subject to all of these caveats, a simple mechanism exists for protecting keyboard input in xterm.

       The xterm menu (see MENUS above) contains a Secure Keyboard entry which, when enabled, attempts to ensure that all keyboard input is directed only to xterm (using the GrabKeyboard protocol request).
       When an application prompts you for a password (or other sensitive data), you can enable Secure Keyboard using the menu, type in the data, and then disable Secure Keyboard using the menu again.

       · This ensures that you know which window is accepting your keystrokes.

       · It cannot ensure that there are no processes which have access to your X display that might be observing the keystrokes as well.

       Only one X client at a time can grab the keyboard, so when you attempt to enable Secure Keyboard it may fail.  In this case, the bell will sound.  If the Secure Keyboard succeeds, the foreground and
       background colors will be exchanged (as if you selected the Enable Reverse Video entry in the Modes menu); they will be exchanged again when you exit secure mode.  If the colors do not switch, then
       you should be very suspicious that you are being spoofed.  If the application you are running displays a prompt before asking for the password, it is safest to enter secure mode before the prompt
       gets displayed, and to make sure that the prompt gets displayed correctly (in the new colors), to minimize the probability of spoofing.  You can also bring up the menu again and make sure that a
       check mark appears next to the entry.

       Secure Keyboard mode will be disabled automatically if your xterm window becomes iconified (or otherwise unmapped), or if you start up a reparenting window manager (that places a title bar or other
       decoration around the window) while in Secure Keyboard mode.  (This is a feature of the X protocol not easily overcome.)  When this happens, the foreground and background colors will be switched
       back and the bell will sound in warning.

--- End quote ---

mrflibble:
For an interesting discussion, see for example: http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html

PKTKS:

Pretty much explained above  just left to comment that

X servers are implicit considered secure using authenticated
keys plus authenticated host access (xhost)

They combined together with a sane firewall policy
put X in a considerable level of confidence.

Any "spyware" in there is not by chance - it was allowed

Paul

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks WYSIWYG Editor
Powered by SMFPacks Advanced Attachments Uploader Mod