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

0 Members and 1 Guest are viewing this topic.

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 3081
  • 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 »
 
The following users thanked this post: perieanuo

Offline madires

  • Super Contributor
  • ***
  • Posts: 6091
  • 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: 2034
  • 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: 2034
  • Country: nl
Re: Xorg security flaw (by design, not a bug)
« Reply #3 on: April 13, 2020, 05:00:22 pm »
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1106
  • 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

  • Super Contributor
  • ***
  • Posts: 1106
  • 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: 496
  • 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

  • Super Contributor
  • ***
  • Posts: 1106
  • 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 »
 
The following users thanked this post: janoc

Offline hli

  • Regular Contributor
  • *
  • Posts: 225
  • 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: 17421
  • 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!
 

Offline 0db

  • Frequent Contributor
  • **
  • Posts: 336
  • 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
 

Offline perieanuo

  • Frequent Contributor
  • **
  • Posts: 665
  • Country: fr
Re: Xorg security flaw (by design, not a bug)
« Reply #11 on: August 19, 2020, 09:52:08 am »
Which attacks? can you name them? :D
are you not being capable of reading?keylogging the terminal of some logged user
you think all attacks are sitting in some xlsx well documented?
 

Online Whales

  • Super Contributor
  • ***
  • Posts: 1263
  • Country: au
    • Halestrom
Re: Xorg security flaw (by design, not a bug)
« Reply #12 on: August 19, 2020, 10:24:17 am »
If you can run code as the user then you have already won, adding restrictions within Xorg will not gain you any security or prevent keylogging whatsoever.  A malicious actor can replace Xorg with their own version and change $PATH, or infect other programs the user runs to log keystrokes in them individually anyway, etc. 

To "fix" this requires going all the way up the chain and designing entirely new paradigms.  Eg running programs as different users and firewalling their IO (there are many projects that do this in various ways, or you can DIY using tools like VNC).

Some of the design decisions made in the Wayland community have been hotly debated; there are big clashes of cultures going in the software world just as we see other cultural clashes in other parts of society.

General advice:
  • Security does not exist in any one individual program.  You have to consider the whole system and what resources different attackers will have to break it.
  • Be cautious about security bloggers, there are a lot of inflammatory opinions and it's worth treating them as carefully as political bloggers.
  • There is no one true security pathway or solution, everything is a compromise.
 
The following users thanked this post: janoc, 0db

Offline jukk

  • Contributor
  • Posts: 38
  • Country: fi
Re: Xorg security flaw (by design, not a bug)
« Reply #13 on: August 19, 2020, 01:39:46 pm »
The only reason I don't use Wayland yet on my main PC is due to Nvidia binary drivers  :horse:

But there are many levels of security. In Redhat/Fedora that I use, there is also for instance SELinux that would prevent a lot of nasty stuff.
 

Offline 0db

  • Frequent Contributor
  • **
  • Posts: 336
  • Country: zm
Re: Xorg security flaw (by design, not a bug)
« Reply #14 on: August 19, 2020, 06:21:07 pm »
Someone suggested the solution to running Xorg as a non-root user is to make /usr/bin/Xorg setuid

That's really worrying  ;D
 

Offline jukk

  • Contributor
  • Posts: 38
  • Country: fi
Re: Xorg security flaw (by design, not a bug)
« Reply #15 on: August 19, 2020, 06:43:00 pm »
Someone suggested the solution to running Xorg as a non-root user is to make /usr/bin/Xorg setuid

That's really worrying  ;D

Not a great idea. I didn't know that some distros still have issues with this. In Fedora Xorg has been running as user since 2013.
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1106
  • Country: br
Re: Xorg security flaw (by design, not a bug)
« Reply #16 on: August 25, 2020, 03:58:59 pm »

Tools for proper user authentication are in place using XDM protocol
which by the way handles all sort of local and remote strict access.

Once properly logged in xdm as the required user why should
anyone care running a stand-alone server other than xdm protocol ?

Paul
 

Offline 0db

  • Frequent Contributor
  • **
  • Posts: 336
  • Country: zm
Re: Xorg security flaw (by design, not a bug)
« Reply #17 on: August 26, 2020, 10:44:33 pm »
I am not sure. By Googling I found that old 90s and 2000s x11-terminals used the X Display Manager Control Protocol. But was/is it really safe?
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1106
  • Country: br
Re: Xorg security flaw (by design, not a bug)
« Reply #18 on: August 27, 2020, 09:07:46 am »
Your search is far from the facts.

Since 2000s the greed of MS made our hardware
property of their licenses. That is only possible
by using a master process (read systemd like)
and proprietary single instance display drivers.

X was developed by hard wired minds
It is full network aware and made to inter
operate among networked hardware

XDM has nothing to do with terminals
it manages several instances of networked
display drivers among heterogeneous users

Safety and hardware independence is top list

Review your way of seeing things..

mostly get rid of systemd concepts of
proprietary single process mastering your
hardware

XDM obviously must be disrupted so to
put that crappy license fees model on
top of the insecure stack of products

typical MS hardware take over
Paul
 

Offline 0db

  • Frequent Contributor
  • **
  • Posts: 336
  • Country: zm
Re: Xorg security flaw (by design, not a bug)
« Reply #19 on: August 27, 2020, 09:48:40 am »
I am not sure. By Googling I found that old 90s and 2000s x11-terminals used the X Display Manager Control Protocol. But was/is it really safe?

Your search is far from the facts.

XDM has nothing to do with terminals it manages several instances of networked display drivers among heterogeneous users

Google reports that "in the early 1990s, several vendors introduced X terminals including Network Computing Devices (NCD), Gipsi, Hewlett Packard (HP), Digital Equipment Corporation (DEC, later absorbed by HP), IBM, Samsung and Tektronix" were equipment designed to connect "to an X display manager (introduced in X11R3) running on a central machine, using XDMCP (X Display Manager Control Protocol, introduced in X11R4)" (Wikipedia, X_terminal)

That's a fact. And I simply asked: was/is it safe?
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1106
  • Country: br
Re: Xorg security flaw (by design, not a bug)
« Reply #20 on: August 27, 2020, 11:19:00 am »
Don't get me wrong

You have mixed concepts quite a lot.

An X terminal has absolute no relation with XDM PROTOCOL.

The XDM PROTOCOL (and all applets which implement that)
is a NETWORKED DISPLAY SERVER aimed to control multi user
access with proper authentication and proper management
of hardware requirements.

It is fully aware of authentication and capable of handling
several users and several displays on a single instance.

Quite the opposite of what systemd and wayland are doing
or trying to disrupt all those tools to put the single display
and license fee model on top of the stack

Forget about any "Terminal" - replace this word with
"DISPLAY MANAGEMENT SERVER"

then include OpenGL aware virtual hosts as well
https://virtualgl.org/

to leverage your vision of things being disrupted
and  mocked by system vendors

A whole above level of system services than
that deep shit pushed by MS and systemd goonies

Just google now for DISPLAY SERVERS and Virtual OGL

Paul
« Last Edit: August 27, 2020, 11:21:17 am by PKTKS »
 
The following users thanked this post: 0db

Offline guenthert

  • Frequent Contributor
  • **
  • Posts: 496
  • Country: us
Re: Xorg security flaw (by design, not a bug)
« Reply #21 on: August 27, 2020, 08:28:37 pm »
I am not sure. By Googling I found that old 90s and 2000s x11-terminals used the X Display Manager Control Protocol. But was/is it really safe?
     An X11 terminal not supporting XDMCP would have been a hard sell.  Strictly speaking you didn't have to use it, if you somehow could convince client applications on a given host to use the X server ("DISPLAY") of the X11 terminal you wished to use;  that seems inconvenient and I doubt it was done a lot.

     Wikipedia states: "One problem with XDMCP is that, similarly to telnet, the authentication takes place unencrypted. If snooping is possible, this leaves the system vulnerable to attack. "   (google for XDMCP and cert and you find further problems).
 You'd have to have a good amount of trust in the security of your network, before using XDMCP, not unlike e.g. NFS.
« Last Edit: August 27, 2020, 08:30:54 pm by guenthert »
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1106
  • Country: br
Re: Xorg security flaw (by design, not a bug)
« Reply #22 on: August 28, 2020, 08:50:34 am »
Today  probably nobody cares running display server connections using telnet as you can run that over ssh with encryption AND compression with far more advantages

It was a hardware limit no longer an issue as modern hardware allows ssh encryption with minimum overhead

Besides ssh also introduced x11 direct support with localized port displays

I have been using it on my intranet servers over a decade just fine... xdmcp over ssh absolute safe and faster

Drawback obviously is modern gpu accel only available after i installed virtual GL over ssh

Paul
 

Offline 0db

  • Frequent Contributor
  • **
  • Posts: 336
  • Country: zm
Re: Xorg security flaw (by design, not a bug)
« Reply #23 on: August 28, 2020, 11:00:02 am »
     An X11 terminal not supporting XDMCP would have been a hard sell. 

According to a colleague here, it seems that on products based on VxWorks had the whole firmware uploaded on the X terminal via tftpboot, so everything was a big files transfer; the OS packeted as file, the windows manager, fonts, applications ... so I can suppose the XDMCP feature was an optional loadable-module.

He is not even sure if the XDMCP module could run a chooser process to perform an XDMCP BroadcastQuery or an XDMCP Query to specified hosts on behalf of the display and offer a menu of possible hosts that offer XDMCP display management.

He just doesn't remember to have ever used it  :-//

Strictly speaking you didn't have to use it, if you somehow could convince client applications on a given host to use the X server ("DISPLAY") of the X11 terminal you wished to use;  that seems inconvenient and I doubt it was done a lot.

     Wikipedia states: "One problem with XDMCP is that, similarly to telnet, the authentication takes place unencrypted. If snooping is possible, this leaves the system vulnerable to attack. "   (google for XDMCP and cert and you find further problems).
 You'd have to have a good amount of trust in the security of your network, before using XDMCP, not unlike e.g. NFS.

Yep, that's still the fear in my head and the reason why I asked "was/is it safe?". Because I was just thinking that basically the Xdm provides services similar to those provided by /sbin/init, /sbin/getty and /sbin/login on character terminals: somehow prompting for login-name and login-password, authenticating the user, and then running a ‘‘session.’’

and ... if it's like telnet or ftp, here is where most of the insecurities go ... because nowadays there are widely-used network protocol analyzer to "sniff" these information - at a microscopic level - over the network.
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1106
  • Country: br
Re: Xorg security flaw (by design, not a bug)
« Reply #24 on: August 28, 2020, 11:13:23 am »
(..)
Yep, that's still the fear in my head and the reason why I asked "was/is it safe?". Because I was just thinking that basically the Xdm provides services similar to those provided by /sbin/init, /sbin/getty and /sbin/login on character terminals: somehow prompting for login-name and login-password, authenticating the user, and then running a ‘‘session.’’
(..)

No. It is not character based - it is an XWindows full graphics oriented.

No. It is not just a plain front end for other authentication applets
It uses it's own mechanisms for authentication and host permissions
and after login in you will also have your shell environment to consider.

I have a full graphic session wide spread over heterogeneous clients

Such setup is not for the sake of selling BUNTU-BANANAS.

It was made from my real needs which came with the advent of
really impractical ways to manage several Gigabytes of shared
libs of EDA applications. KiCAD and FreeCAD  repository locally
mixed with my own models and SPICE and other stuff gathered
along decades needing to be perfectly synche'd available to
clients over the intranet from the common NAS.

Attached a figure dating from the early days (some years ago)
where I just worked around the problem of must having GPU
accel over clients over XDM connections...

This is my setup - obviously not meant to sell buntu-bananas...

i think i had placed this sketch already...
Paul
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf