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

0 Members and 1 Guest are viewing this topic.

Online 0db

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: zm
Re: Xorg security flaw (by design, not a bug)
« Reply #25 on: August 28, 2020, 11:21:19 am »
xdmcp over ssh absolute safe and faster

so that's the "cure" :D
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3184
  • Country: fr
Re: Xorg security flaw (by design, not a bug)
« Reply #26 on: August 28, 2020, 12:41:49 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.

Which is by design, e.g. Windows has exactly the same thing.


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

Um, nope.

Only applications that you are running could potentially snoop on other apps that are running on the same display under your UID. Which is completely fine - if you are running the code under your user account, then the fact it could spy on some other window is the least of your problems. By that time it could have easily copied or deleted all your data.

Other applications, running  under different user IDs are unable to access your display (whether to snoop the keyboard or display stuff on your screen).  Not even applications running as the superuser (root) can snoop on your display using this mechanism without some help (of course, they could do other things).
 
This is ensured by multiple mechanisms, the most common are the xhost access control (you can allow someone else to access your display) and by the MIT-MAGIC-COOKIE mechanism:

https://stackoverflow.com/questions/37157097/how-does-x11-authorization-works-mit-magic-cookie

The cookies are stored in the .Xauthority file in your home directory and protected by regular file permissions. If the application doesn't present the correct cookie (and if it is an app of some other user, it can't access it), the X server will refuse the connection.

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?   :-//

Because it is not a vulnerability - the only windows that are "vulnerable" are those that are running under the same UID as the hypothetical malware, otherwise the malware wouldn't be able to obtain the necessary cookie and connect to the server. I.e. you would have to run the malware yourself.

Furthermore, that mechanism is essential for things like input methods, injecting keystrokes into apps for testing, etc.

Long time ago (and I mean like 25-30 years) when X terminals were still in use and Unix (not Linux) workstations were common, the X servers often shipped widely open, with access control disabled (equivalent to setting "xhost +"). At the time something like malware or spyware was not a threat and these things were used on trusted networks - like companies or university labs, so some heavy security wasn't needed even though the facilities did exist from pretty early on (university students can be very resourceful). On such machines this "attack" was possible - in fact, a common joke was to harass the hapless colleagues by displaying e.g. xeyes on their on screen remotely or messing with their windows. People have learned to put "xhost -" in their login scripts pretty quickly.

Linux distros didn't ship unsecured/open by default X server since at least 20 years ago, possibly longer - I remember the instructions on how to secure XFree86 if you are running it back from the days of Slackware on 20 floppies and never had to do it afterwards.


If someone uses this as an argument for Wayland, they really have no idea what they are talking about. Wayland certainly has benefits - but this isn't the one.

« Last Edit: August 28, 2020, 01:00:11 pm by janoc »
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3184
  • Country: fr
Re: Xorg security flaw (by design, not a bug)
« Reply #27 on: August 28, 2020, 12:57:44 pm »
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?

Then are you just handwaving or do you really have evidence of such attack actually having occurred in the last 20 years or so?

Before that it could have happened, because both X terminals and commercial Unix workstations were common and often shipped with X11 access controls disabled by default.

Keylogger attacks on Linux are extremely rare, there are much much easier ways for an attacker to get what they want (usually data or access) once they can execute code under your user ID (which is required in order to exploit this "vulnerability").
 

Offline PKTKS

  • Frequent Contributor
  • **
  • Posts: 599
  • Country: br
Re: Xorg security flaw (by design, not a bug)
« Reply #28 on: August 28, 2020, 01:43:46 pm »
(..)
This is ensured by multiple mechanisms, the most common are the xhost access control (you can allow someone else to access your display) and by the MIT-MAGIC-COOKIE mechanism:

https://stackoverflow.com/questions/37157097/how-does-x11-authorization-works-mit-magic-cookie

The cookies are stored in the .Xauthority file in your home directory and protected by regular file permissions. If the application doesn't present the correct cookie (and if it is an app of some other user, it can't access it), the X server will refuse the connection.
(..)

Exactly.

Your clients are required to own the MIT "cookie" which must
be previously granted for them to have display authoritative access

... BTW regarding that comment on "character" terminals...

It seems the man page is missing a comma so to correctly read
the statement... once terminals are mere clients over XDMCP protocol
in which case may be encapsulated (and today 100% are over ssh) over
another secure transport stream.

Just read the man again and try to add missing commas for correct reading

Paul
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf