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.
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-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.
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.