Xorg security flaw (by design, not a bug) - Page 1
Forum section: electronics / general

author: RoGeorge
author_rank: Super Contributor
timestamp: April 12, 2020, 06:18:07 pm
content: 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 (https://www.secjuice.com/wayland-vs-xorg/)~$ # 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.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?

author: madires
author_rank: Super Contributor
timestamp: April 12, 2020, 06:37:25 pm
content: 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.

author: mrflibble
author_rank: Super Contributor
timestamp: April 13, 2020, 04:43:25 pm
content: 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

author: mrflibble
author_rank: Super Contributor
timestamp: April 13, 2020, 05:00:22 pm
content: For an interesting discussion, see for example:http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html

author: PKTKS
author_rank: Super Contributor
timestamp: April 13, 2020, 07:58:27 pm
content: Pretty much explained above just left to comment thatX servers are implicit considered secure using authenticatedkeys plus authenticated host access (xhost)They combined together with a sane firewall policyput X in a considerable level of confidence.Any "spyware" in there is not by chance - it was allowedPaul

author: PKTKS
author_rank: Super Contributor
timestamp: April 13, 2020, 08:04:08 pm
content: And BTW is very important to comment as wellthat one of the **MAIN REASONS** to dismissbad and crappy SHIT like systemd thingsis the followingthere are already all the things in place to raise securityA process (a single process like systemd)actually is a tragedy for all the rest of the systemas that process have priority to override some or all policy.Init and systemv obviously are secure by default they just raise PID 0If possible get rid of systemd - it is a tragedy by designPaul

author: guenthert
author_rank: Frequent Contributor
timestamp: June 17, 2020, 04:54:53 pm
content: Quote from: RoGeorge on April 12, 2020, 06:18:07 pmAs 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 ...

author: PKTKS
author_rank: Super Contributor
timestamp: June 17, 2020, 08:20:18 pm
content: Quote from: guenthert on June 17, 2020, 04:54:53 pmJust 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 amongclients inside the DMZ offering a very convenient safe loginin all workstations and boxesAll security X11 offers are in place with proper DMZ andcarefully 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 notreplace the all good network functions of X11.Running daily without a single issue in over 2 decades?I consider that above OKWhat really bothers me are the closed source X driverswhich we are "forced" to run when GPU accel is required(read NV AMD)Paul

author: hli
author_rank: Frequent Contributor
timestamp: June 17, 2020, 09:56:35 pm
content: Quote from: RoGeorge on April 12, 2020, 06:18:07 pmThe 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.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 18, 2020, 01:10:39 am
content: 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

author: 0db
author_rank: Frequent Contributor
timestamp: June 18, 2020, 09:27:36 pm
content: Which attacks? can you name them?

author: perieanuo
author_rank: Frequent Contributor
timestamp: August 19, 2020, 09:52:08 am
content: Quote from: 0db on June 18, 2020, 09:27:36 pmare you not being capable of reading?keylogging the terminal of some logged useryou think all attacks are sitting in some xlsx well documented?

author: Whales
author_rank: Super Contributor
timestamp: August 19, 2020, 10:24:17 am
content: 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.

author: JohanH
author_rank: Frequent Contributor
timestamp: August 19, 2020, 01:39:46 pm
content: The only reason I don't use Wayland yet on my main PC is due to Nvidia binary driversBut 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.

author: 0db
author_rank: Frequent Contributor
timestamp: August 19, 2020, 06:21:07 pm
content: Someone suggested the solution to running Xorg as a non-root user is to make /usr/bin/Xorg setuidThat's really worrying

author: JohanH
author_rank: Frequent Contributor
timestamp: August 19, 2020, 06:43:00 pm
content: Quote from: 0db on August 19, 2020, 06:21:07 pmNot 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.

author: PKTKS
author_rank: Super Contributor
timestamp: August 25, 2020, 03:58:59 pm
content: Tools for proper user authentication are in place using XDM protocolwhich by the way handles all sort of local and remote strict access.Once properly logged in xdm as the required user why shouldanyone care running a stand-alone server other than xdm protocol ?Paul

author: 0db
author_rank: Frequent Contributor
timestamp: August 26, 2020, 10:44:33 pm
content: 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?

author: PKTKS
author_rank: Super Contributor
timestamp: August 27, 2020, 09:07:46 am
content: Your search is far from the facts.Since 2000s the greed of MS made our hardwareproperty of their licenses. That is only possibleby using a master process (read systemd like)and proprietary single instance display drivers.X was developed by hard wired mindsIt is full network aware and made to interoperate among networked hardwareXDM has nothing to do with terminalsit manages several instances of networkeddisplay drivers among heterogeneous usersSafety and hardware independence is top listReview your way of seeing things..mostly get rid of systemd concepts ofproprietary single process mastering yourhardwareXDM obviously must be disrupted so toput that crappy license fees model ontop of the insecure stack of productstypical MS hardware take overPaul

author: 0db
author_rank: Frequent Contributor
timestamp: August 27, 2020, 09:48:40 am
content: Quote from: 0db on August 26, 2020, 10:44:33 pmQuote from: PKTKS on August 27, 2020, 09:07:46 amQuote from: PKTKS on August 27, 2020, 09:07:46 amGoogle 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?

author: PKTKS
author_rank: Super Contributor
timestamp: August 27, 2020, 11:19:00 am
content: Don't get me wrongYou 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 useraccess with proper authentication and proper managementof hardware requirements.It is fully aware of authentication and capable of handlingseveral users and several displays on a single instance.Quite the opposite of what systemd and wayland are doingor trying to disrupt all those tools to put the single displayand license fee model on top of the stackForget about any "Terminal" - replace this word with"DISPLAY MANAGEMENT SERVER"then include OpenGL aware virtual hosts as wellhttps://virtualgl.org/to leverage your vision of things being disruptedand mocked by system vendorsA whole above level of system services thanthat deep shit pushed by MS and systemd gooniesJust google now for DISPLAY SERVERS and Virtual OGLPaul

author: guenthert
author_rank: Frequent Contributor
timestamp: August 27, 2020, 08:28:37 pm
content: Quote from: 0db on August 26, 2020, 10:44:33 pmAn 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.

author: PKTKS
author_rank: Super Contributor
timestamp: August 28, 2020, 08:50:34 am
content: Today probably nobody cares running display server connections using telnet as you can run that over ssh with encryption AND compression with far more advantagesIt was a hardware limit no longer an issue as modern hardware allows ssh encryption with minimum overheadBesides ssh also introduced x11 direct support with localized port displaysI have been using it on my intranet servers over a decade just fine... xdmcp over ssh absolute safe and fasterDrawback obviously is modern gpu accel only available after i installed virtual GL over sshPaul

author: 0db
author_rank: Frequent Contributor
timestamp: August 28, 2020, 11:00:02 am
content: Quote from: guenthert on August 27, 2020, 08:28:37 pmAccording 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 itQuote from: guenthert on August 27, 2020, 08:28:37 pmYep, 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.

author: PKTKS
author_rank: Super Contributor
timestamp: August 28, 2020, 11:13:23 am
content: Quote from: 0db on August 28, 2020, 11:00:02 amNo. It is not character based - it is an XWindows full graphics oriented.No. It is not just a plain front end for other authentication appletsIt uses it's own mechanisms for authentication and host permissionsand after login in you will also have your shell environment to consider.I have a full graphic session wide spread over heterogeneous clientsSuch setup is not for the sake of selling BUNTU-BANANAS.It was made from my real needs which came with the advent ofreally impractical ways to manage several Gigabytes of sharedlibs of EDA applications. KiCAD and FreeCAD repository locallymixed with my own models and SPICE and other stuff gatheredalong decades needing to be perfectly synche'd available toclients 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 GPUaccel 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

author: 0db
author_rank: Frequent Contributor
timestamp: August 28, 2020, 11:21:19 am
content: Quote from: PKTKS on August 28, 2020, 08:50:34 amso that's the "cure"

author: janoc
author_rank: Super Contributor
timestamp: August 28, 2020, 12:41:49 pm
content: Quote from: RoGeorge on April 12, 2020, 06:18:07 pmWhich is by design, e.g. Windows has exactly the same thing.Quote from: RoGeorge on April 12, 2020, 06:18:07 pmUm, nope.Only applicationsthat you are runningcould 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-cookieThe 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.Quote from: RoGeorge on April 12, 2020, 06:18:07 pmBecause it isnot 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.

author: janoc
author_rank: Super Contributor
timestamp: August 28, 2020, 12:57:44 pm
content: Quote from: perieanuo on August 19, 2020, 09:52:08 amThen 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 (whichis requiredin order to exploit this "vulnerability").

author: PKTKS
author_rank: Super Contributor
timestamp: August 28, 2020, 01:43:46 pm
content: Quote from: janoc on August 28, 2020, 12:41:49 pmExactly.Your clients are required to own the MIT "cookie" which mustbe 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 readthe statement... once terminals are mere clients over XDMCP protocolin which case may be encapsulated (and today 100% are over ssh) overanother secure transport stream.Just read the man again and try to add missing commas for correct readingPaul