Author Topic: Xorg security flaw (by design, not a bug)  (Read 638 times)

0 Members and 1 Guest are viewing this topic.

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 2388
  • Country: ro
Xorg security flaw (by design, not a bug)
« on: April 12, 2020, 06:18:07 pm »
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: [Select]
    ~$ # 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.

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?   :-//
« Last Edit: April 12, 2020, 06:23:58 pm by RoGeorge »
 

Offline madires

  • Super Contributor
  • ***
  • Posts: 5261
  • Country: de
  • A qualified hobbyist ;)
Re: Xorg security flaw (by design, not a bug)
« Reply #1 on: April 12, 2020, 06:37:25 pm »
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.
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2018
  • Country: nl
Re: Xorg security flaw (by design, not a bug)
« Reply #2 on: April 13, 2020, 04:43:25 pm »
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.
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2018
  • Country: nl
Re: Xorg security flaw (by design, not a bug)
« Reply #3 on: April 13, 2020, 05:00:22 pm »
 

Offline PKTKS

  • Frequent Contributor
  • **
  • Posts: 571
  • Country: br
Re: Xorg security flaw (by design, not a bug)
« Reply #4 on: April 13, 2020, 07:58:27 pm »

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
 

Offline PKTKS

  • Frequent Contributor
  • **
  • Posts: 571
  • Country: br
Re: Xorg security flaw (by design, not a bug)
« Reply #5 on: April 13, 2020, 08:04:08 pm »
And BTW  is very  important to comment as well
that  one of the **MAIN REASONS** to  dismiss
bad and crappy  SHIT  like systemd  things

is the following
there are already all the things in place to raise security

A process (a single process like systemd)
actually  is a tragedy for all the rest of the system
as that process have priority to override some or all policy.

Init and systemv  obviously are secure by default they just raise PID 0

If possible get rid of systemd - it is a tragedy by design

Paul
« Last Edit: April 13, 2020, 08:07:04 pm by PKTKS »
 

Offline guenthert

  • Frequent Contributor
  • **
  • Posts: 387
  • Country: us
Re: Xorg security flaw (by design, not a bug)
« Reply #6 on: June 17, 2020, 04:54:53 pm »
[..]
I don't get it, why the X server was designed like that, and how that nobody complains about such a vulnerability?   :-//
  As has already been stated, it's been designed in an era when computer security wasn't first priority (meant for academic and commercial application, not military) and debug-ability was more important.  Further, the old thinking was, that if any antagonist managed to run a (non-privileged) process on your computer, the battle was already lost, as there were always some privilege escalations on Unix to be found.  That was long before everyone was happily running Javascript from sites they didn't even know they accessed ...

  It comes up every now and then, particularly by those promoting Wayland.

If you are (or rather have reasons to be) serious about security, don't run X11.

Me, I rather wonder about all those connections to Russian servers my Android phone makes ...
« Last Edit: June 17, 2020, 04:57:15 pm by guenthert »
 

Offline PKTKS

  • Frequent Contributor
  • **
  • Posts: 571
  • Country: br
Re: Xorg security flaw (by design, not a bug)
« Reply #7 on: June 17, 2020, 08:20:18 pm »
(..)
If you are (or rather have reasons to be) serious about security, don't run X11.
(..)


Just not true.  Indeed a very shallow statement.

I run X11 for about 2/3 decades daily without a single issue.
For the record my display servers are fully functional among
clients inside the DMZ offering a very convenient safe login
in all workstations and boxes

All security X11 offers are in place with proper DMZ and
carefully taken measures.

It is an order of magnitude more secure just by being open source than
 **ANY** other closed source display server you can think of.

There is a trend to promote Wayland which IMHO will not
replace the all good network functions of X11.

Running daily without a single issue in over 2 decades?

I consider that above OK

What really bothers me are the closed source X drivers
which we are "forced" to run when GPU accel is required
(read NV AMD)

Paul
« Last Edit: June 17, 2020, 08:24:49 pm by PKTKS »
 

Offline hli

  • Regular Contributor
  • *
  • Posts: 200
  • Country: de
Re: Xorg security flaw (by design, not a bug)
« Reply #8 on: June 17, 2020, 09:56:35 pm »
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

The question here is: what is your thread model? That is - how do you think you are getting attacked? If you need to worry about running untrusted software: yes, maybe X11 could be a door for keylogger. But so can (probably countless) other programs on your machine (without further checking I would guess that any software running under your user account can read all keyboard inputs if it wants to, by using all of the exposed devices). The problem here is 'running untrusted software', not the one known problem you currently know about.
Yes, for defense-in-depth it would be _very_ helpful if X11 would do this different. But when someone can run software on your computer that can access the X11 system you probably have bigger problems.
 

Offline T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 15255
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: Xorg security flaw (by design, not a bug)
« Reply #9 on: June 18, 2020, 01:10:39 am »
For point of reference, that sounds essentially identical to the situation on Windows.  So it's no worse than the majority of systems in the world, which largely don't have problems with the described attacks because the attacks aren't ran on them in the first place (the most common exception being a newly discovered RCE 0-day, or tricking the user into running malicious code; neither of which the alternative is especially immune to, as comparable exploits have been demonstrated on *nix over the years).  (In short, if you need a greater measure of security against such attacks, a lower level approach, like air gapping, will be far more effective.)

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Online 0db

  • Regular Contributor
  • *
  • Posts: 185
  • Country: zm
Re: Xorg security flaw (by design, not a bug)
« Reply #10 on: June 18, 2020, 09:27:36 pm »
Which attacks? can you name them? :D
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf