~$ # 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.
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.
[..]
I don't get it, why the X server was designed like that, and how that nobody complains about such a vulnerability?
(..)
If you are (or rather have reasons to be) serious about security, don't run X11.
(..)
This means any window in Xorg could be a keylogger, and could spy for passwords or other sensitive data typed in any other window.
Which attacks? can you name them?
Someone suggested the solution to running Xorg as a non-root user is to make /usr/bin/Xorg setuid
That's really worrying
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
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.
(..)
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.’’
(..)