28 ms·

Good that people are finding and fixing these, but basically allowing any untrusted client to talk to your X server is asking for trouble just by design. (Bonu

by rwmj 1y ago

Good that people are finding and fixing these, but basically allowing any untrusted client to talk to your X server is asking for trouble just by design. (Bonus points if you have any Tcl/Tk apps running, where you can simply transmit commands for the program to run via the X server.)

hulitu 1y ago
You do realize that your web browser is executing code feeded by remote servers (RCE). But it is important to fix the windowing system. /s
jeroenhd 1y ago
There are plenty of setups where the X server runs at higher privileges/on a different host than the (partially trusted) application that might exploit the X server. This is a classic elevation of privileges vulnerability in those setups. X11's practical absence of any security mechanisms for user sessions means you should probably not run any kind of low-trust UI program anyway, as there is no prevention of keystroke injection or screen recording, but that's a design flaw that will never be solved. That doesn't mean that EoP style attacks like these should be ignored or underestimated, though.
- mrktf 1y ago
  Digging deeper there are mechanisms for long time on internal X side (see https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserver/XACE-Spec.html https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserv... ) - granted never seen it practically implemented. And going to rabbit hole there are even proof of concept security implementation named Xnamespace for Xorg fork (needs polishing and much more patches but looks doable. see wip documentation: https://raw.githubusercontent.com/X11Libre/xserver/d2b60a3d6c753fa4dd43b4ffd84a8ec49d44912f/doc/Xnamespace.md https://raw.githubusercontent.com/X11Libre/xserver/d2b60a3d6... )
  - lotharcable 1y ago
    The way X11 developers ended up fixing this is by creating Wayland. This way privileged operations (like keylogging, screen capture, etc) require the cooperation and authentication through the display server.
    - deleted 1y ago
      [deleted]
    - embedding-shape 1y ago
      That way you also prevent things possible in X11 to be impossible in Wayland, like a window setting it's own position, if you were to want that.
      - lotharcable 1y ago
        Fixing X11's security would of broken window positioning as well. Since that is a security issue. The deal here is that the only way to fix X11's security issues is by breaking all those types of workflows and forcing application rewrites to implement them in authenticated ways. So if you are going have to go and break all that stuff, why not fix a crapload of other problems while you are at it? Calling Wayland "X13" may have avoided a lot of misunderstandings, but it probably would of caused others.
        embedding-shape 1y ago
        > Since that is a security issue. Maybe it's both? There are applications with good reason that need to chose their location themselves, and users who want that type of behavior, so it's definitively not just a security issue.
      - accelbred 1y ago
        Good. Disallowing software to position its own windows has been a major usability improvement over the X11 days of software making stupid positioning decisions and having to patch it out everywhere...
- mikkupikku 1y ago
  I don't think I've seen X configured to run as root in probably 15 years. If anybody still does anything like that, they're literally asking for it.
  - _flux 1y ago
    Hmm.. On my Debian ps axuw|grep Xorg says root 34595 2.7 0.4 26146280 532248 tty4 Sl+ Nov13 783:33 /usr/lib/xorg/Xorg vt4 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 3
    - asveikau 1y ago
      That looks like the display manager (i.e. login screen) running on vt4, which is probably not where you are logged in. Does it switch to another user when you log in? Note you have multiple virtual consoles which can have independent X servers.
      - _flux 1y ago
        No, that's actually my real and only Xorg, it's the child process of /usr/libexec/gdm-x-session and that process is owned by my real user id, and the Xorg process provides /tmp/.X11-unix/X1 that e.g. strace -e connect xlsclients shows is the socket it uses. Notice also that it uses a significant amount of memory and has consumed a meaningful amount of CPU time, much more than a dm would do. Good point about display manager though, I suppose it's not using Xorg then as I do know there is a login screen waiting at vt1 but that's the only Xorg process. Maybe the gdm3 incorporates a Wayland implementation in Debian 13.
      - josefx 1y ago
        I think I ran into some display managers that do not start a new X session for every user. However I was trying out some rather non standard configurations at the time, some of which required root access for driver specific features.
- uecker 1y ago
  X11 had the distinction between trusted and untrusted X11 clients basically forever. But nobody bothered to even spend the minimal amount of work to make this usable in practice^1. This had two reasons: 1.) It is irrelevant when you run the programs as the same user so nobody bothered (and no: Wayland does not help: https://github.com/Aishou/wayland-keylogger https://github.com/Aishou/wayland-keylogger) 2.) It is more fun to simply pretend it is unfixable broken and write something new (something any good engineering manager should have stopped immediately). ¹. I used to use this and also fixed some bugs in some programs. The main problem when I last checked a decade ag was that some important extensions such as composite would need to be exposed to untrusted clients.
  - rich66man 1y ago
    > something any good engineering manager should have stopped immediately Who exactly should and can control the horde of OSS developers?
    - DarkmSparks 1y ago
      They were paid by redhat.
    - justin66 1y ago
      [flagged]
      - deleted 1y ago
        [deleted]
  - Jasper_ 1y ago
    That Wayland keylogger is not the same thing. X11 has several mechanisms (XTest, XRecord, XI raw inputs) to receive a global raw key input stream, accessible to anyone who connects to the X server, without even making a visible window surface. It even bypasses grabs, meaning that your lock screen password entry can be snooped on. The Wayland keylogger acts like an application; all Wayland compositors will only send key events to the focused surface, so the user has to focus an active surface in order to get key events. Even in the scenario where you've LD_PRELOAD-hooked all applications, you still will never get the lock screen password, as the compositor never sends it out across the wire. LD_PRELOAD is problematic from a security perspective, but it's not Wayland-specific: the same issue is true for CLI applications and X11 applications, and any attacker with the ability to write files could also just replace your binaries with malicious ones (stuff them somewhere into ~/.hidden, and then add a $PATH entry to the start).
- 0xbadcafebee 1y ago
  Why do people keep persisting this myth? X11 has authentication. You can either rely on filesystem permissions, or a shared secret. The same way thousands of other network servers work. Any program you run on a computer (especially a Linux computer, which lacks modern OS security measures and has constant privesc kernel holes) exposes you to security flaws. There has yet to be any computer system designed that a hacker can't break out of. If you intentionally download and execute a program, you are rolling the dice, regardless of what the software is. What's insane about all these discussions is that NOBODY IS HACKING X SERVERS. There's a thousand other kinds of software on Linux that there is real malware for. But nobody is trying to hijack your X11 session. This imagined threat is a red herring designed to bolster the argument for Wayland's horrible designs.
  - tapoxi 1y ago
    I think the issue isn't that you downloaded random hostile software, but that other software you do use has some sort of vulnerability (recent Unity vulnerability, browser sandbox escape, etc) and an issue like this would allow for privilege escalation. Wayland doesn't need X11's vulnerability as its only argument, Wayland is a much simpler design that is easier to iterate on because it doesn't assume the client and server are on different machines. The fact that it moves privileged APIs like screen capture behind portals is a bonus.
    - kelnos 1y ago
      So simple and easy to iterate on that Wayland compositors are still not as full-featured as X11 desktop environments after more then a decade, and can't be due to protocols no one is able to agree to implement.
      - phkahler 1y ago
        >> Wayland compositors are still not as full-featured as X11 desktop environments It depends what features you care about. X11 doesn't have tear-free video playback, HDR, or as good a security model as Wayland.
- udev4096 1y ago
  Any application can literally log EVERYTHING! It's good to see wayland getting better everyday
- shrubble 1y ago
  Solaris had Trusted Extensions for X11 which shipped with Trusted Solaris 8. In 2000. Solaris 10 had it built into the base OS and integrated into both the CDE and GNOME desktops they shipped. With OpenSolaris it was released as open source under the non-GNU CDDL license. In November 2006. Wayland was started in 2008.
- enriquto 1y ago
  > X11's practical absence of any security mechanisms for user sessions means you should probably not run any kind of low-trust UI program This has nothing to do with X11 or even UI at all. You should not run any low-trust program whatsoever (outside of a container). Any program that runs as your user can change your ~/.bashrc or any other file on your homedir. Of course this is a feature that you want, for example when you edit these files with a text editor.
deleted 1y ago
[deleted]
exasperaited 1y ago
> Bonus points if you have any Tcl/Tk apps running, where you can simply transmit commands for the program to run via the X server. Back in 1996 the level of X integration in Tk was awesome; I had a shell tool that could make Netscape do stuff by firing MIT magic cookies at it. In a contemporary setting, it's pretty horrifying.
- ptx 1y ago
  Didn't Netscape use Motif?
  - exasperaited 1y ago
    It did, but it could receive messages thanks to MIT Magic Cookies, which you could send because of Tk’s excellent integration with X. I can’t remember now if it was the browser you could also effectively spy on via similar means. Long time ago. I have largely forgotten how my tool worked now but the code I wrote (modified wish shell) might still be out there.
shevy-java 1y ago
Some oldschool legends are still fixing bugs in xorg. Alan Coopersmith in particular. He even fixed a bug I reported. :) (I forgot in which app it was but the bug report should be somewhere still; it is not old, perhaps 2 years ago or 3 years ago. The xorg app in question behaved oddly when doing "--version". I only noticed this because I wrote a ruby script that displays which version of programs are installed, and that one kept on making problems, whereas the others worked fine. After I reported it, Alan fixed this very quickly. I think it was some missing flag in the C program or something like that; right now I can not remember the name of the program ... my brain tries to say xrandr but I think it was not xrandr but a less frequently used program somewhere in the FTP listing ...)
- ElectroBuffoon 1y ago
  Keith Packard, another legend, was proposing X11 improvements in 2018. [0] He doesn't seem to be paid to work in X11 or Wayland, thus being free to float ideas he likes. [0] https://keithp.com/x-ideas/ https://keithp.com/x-ideas/
bitwize 1y ago
These are all "no way to prevent this, say users of only language where this regularly happens" type problems though. The send command in Tk is lel, but can easily be effectively closed by rebinding it to a no-op.

by rwmj 1y ago

hulitu 1y ago

You do realize that your web browser is executing code feeded by remote servers (RCE). But it is important to fix the windowing system. /s

jeroenhd 1y ago

There are plenty of setups where the X server runs at higher privileges/on a different host than the (partially trusted) application that might exploit the X server. This is a classic elevation of privileges vulnerability in those setups. X11's practical absence of any security mechanisms for user sessions means you should probably not run any kind of low-trust UI program anyway, as there is no prevention of keystroke injection or screen recording, but that's a design flaw that will never be solved. That doesn't mean that EoP style attacks like these should be ignored or underestimated, though.

mrktf 1y ago
Digging deeper there are mechanisms for long time on internal X side (see https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserver/XACE-Spec.html https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserv... ) - granted never seen it practically implemented. And going to rabbit hole there are even proof of concept security implementation named Xnamespace for Xorg fork (needs polishing and much more patches but looks doable. see wip documentation: https://raw.githubusercontent.com/X11Libre/xserver/d2b60a3d6c753fa4dd43b4ffd84a8ec49d44912f/doc/Xnamespace.md https://raw.githubusercontent.com/X11Libre/xserver/d2b60a3d6... )
- lotharcable 1y ago
  The way X11 developers ended up fixing this is by creating Wayland. This way privileged operations (like keylogging, screen capture, etc) require the cooperation and authentication through the display server.
  - deleted 1y ago
    [deleted]
  - embedding-shape 1y ago
    That way you also prevent things possible in X11 to be impossible in Wayland, like a window setting it's own position, if you were to want that.
    - lotharcable 1y ago
      Fixing X11's security would of broken window positioning as well. Since that is a security issue. The deal here is that the only way to fix X11's security issues is by breaking all those types of workflows and forcing application rewrites to implement them in authenticated ways. So if you are going have to go and break all that stuff, why not fix a crapload of other problems while you are at it? Calling Wayland "X13" may have avoided a lot of misunderstandings, but it probably would of caused others.
      - embedding-shape 1y ago
        > Since that is a security issue. Maybe it's both? There are applications with good reason that need to chose their location themselves, and users who want that type of behavior, so it's definitively not just a security issue.
    - accelbred 1y ago
      Good. Disallowing software to position its own windows has been a major usability improvement over the X11 days of software making stupid positioning decisions and having to patch it out everywhere...
mikkupikku 1y ago
I don't think I've seen X configured to run as root in probably 15 years. If anybody still does anything like that, they're literally asking for it.
- _flux 1y ago
  Hmm.. On my Debian ps axuw|grep Xorg says root 34595 2.7 0.4 26146280 532248 tty4 Sl+ Nov13 783:33 /usr/lib/xorg/Xorg vt4 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 3
  - asveikau 1y ago
    That looks like the display manager (i.e. login screen) running on vt4, which is probably not where you are logged in. Does it switch to another user when you log in? Note you have multiple virtual consoles which can have independent X servers.
    - _flux 1y ago
      No, that's actually my real and only Xorg, it's the child process of /usr/libexec/gdm-x-session and that process is owned by my real user id, and the Xorg process provides /tmp/.X11-unix/X1 that e.g. strace -e connect xlsclients shows is the socket it uses. Notice also that it uses a significant amount of memory and has consumed a meaningful amount of CPU time, much more than a dm would do. Good point about display manager though, I suppose it's not using Xorg then as I do know there is a login screen waiting at vt1 but that's the only Xorg process. Maybe the gdm3 incorporates a Wayland implementation in Debian 13.
    - josefx 1y ago
      I think I ran into some display managers that do not start a new X session for every user. However I was trying out some rather non standard configurations at the time, some of which required root access for driver specific features.
uecker 1y ago
X11 had the distinction between trusted and untrusted X11 clients basically forever. But nobody bothered to even spend the minimal amount of work to make this usable in practice^1. This had two reasons: 1.) It is irrelevant when you run the programs as the same user so nobody bothered (and no: Wayland does not help: https://github.com/Aishou/wayland-keylogger https://github.com/Aishou/wayland-keylogger) 2.) It is more fun to simply pretend it is unfixable broken and write something new (something any good engineering manager should have stopped immediately). ¹. I used to use this and also fixed some bugs in some programs. The main problem when I last checked a decade ag was that some important extensions such as composite would need to be exposed to untrusted clients.
- rich66man 1y ago
  > something any good engineering manager should have stopped immediately Who exactly should and can control the horde of OSS developers?
  - DarkmSparks 1y ago
    They were paid by redhat.
  - justin66 1y ago
    [flagged]
    - deleted 1y ago
      [deleted]
- Jasper_ 1y ago
  That Wayland keylogger is not the same thing. X11 has several mechanisms (XTest, XRecord, XI raw inputs) to receive a global raw key input stream, accessible to anyone who connects to the X server, without even making a visible window surface. It even bypasses grabs, meaning that your lock screen password entry can be snooped on. The Wayland keylogger acts like an application; all Wayland compositors will only send key events to the focused surface, so the user has to focus an active surface in order to get key events. Even in the scenario where you've LD_PRELOAD-hooked all applications, you still will never get the lock screen password, as the compositor never sends it out across the wire. LD_PRELOAD is problematic from a security perspective, but it's not Wayland-specific: the same issue is true for CLI applications and X11 applications, and any attacker with the ability to write files could also just replace your binaries with malicious ones (stuff them somewhere into ~/.hidden, and then add a $PATH entry to the start).
0xbadcafebee 1y ago
Why do people keep persisting this myth? X11 has authentication. You can either rely on filesystem permissions, or a shared secret. The same way thousands of other network servers work. Any program you run on a computer (especially a Linux computer, which lacks modern OS security measures and has constant privesc kernel holes) exposes you to security flaws. There has yet to be any computer system designed that a hacker can't break out of. If you intentionally download and execute a program, you are rolling the dice, regardless of what the software is. What's insane about all these discussions is that NOBODY IS HACKING X SERVERS. There's a thousand other kinds of software on Linux that there is real malware for. But nobody is trying to hijack your X11 session. This imagined threat is a red herring designed to bolster the argument for Wayland's horrible designs.
- tapoxi 1y ago
  I think the issue isn't that you downloaded random hostile software, but that other software you do use has some sort of vulnerability (recent Unity vulnerability, browser sandbox escape, etc) and an issue like this would allow for privilege escalation. Wayland doesn't need X11's vulnerability as its only argument, Wayland is a much simpler design that is easier to iterate on because it doesn't assume the client and server are on different machines. The fact that it moves privileged APIs like screen capture behind portals is a bonus.
  - kelnos 1y ago
    So simple and easy to iterate on that Wayland compositors are still not as full-featured as X11 desktop environments after more then a decade, and can't be due to protocols no one is able to agree to implement.
    - phkahler 1y ago
      >> Wayland compositors are still not as full-featured as X11 desktop environments It depends what features you care about. X11 doesn't have tear-free video playback, HDR, or as good a security model as Wayland.
udev4096 1y ago
Any application can literally log EVERYTHING! It's good to see wayland getting better everyday
shrubble 1y ago
Solaris had Trusted Extensions for X11 which shipped with Trusted Solaris 8. In 2000. Solaris 10 had it built into the base OS and integrated into both the CDE and GNOME desktops they shipped. With OpenSolaris it was released as open source under the non-GNU CDDL license. In November 2006. Wayland was started in 2008.
enriquto 1y ago
> X11's practical absence of any security mechanisms for user sessions means you should probably not run any kind of low-trust UI program This has nothing to do with X11 or even UI at all. You should not run any low-trust program whatsoever (outside of a container). Any program that runs as your user can change your ~/.bashrc or any other file on your homedir. Of course this is a feature that you want, for example when you edit these files with a text editor.

deleted 1y ago

[deleted]

exasperaited 1y ago

> Bonus points if you have any Tcl/Tk apps running, where you can simply transmit commands for the program to run via the X server. Back in 1996 the level of X integration in Tk was awesome; I had a shell tool that could make Netscape do stuff by firing MIT magic cookies at it. In a contemporary setting, it's pretty horrifying.

ptx 1y ago
Didn't Netscape use Motif?
- exasperaited 1y ago
  It did, but it could receive messages thanks to MIT Magic Cookies, which you could send because of Tk’s excellent integration with X. I can’t remember now if it was the browser you could also effectively spy on via similar means. Long time ago. I have largely forgotten how my tool worked now but the code I wrote (modified wish shell) might still be out there.

shevy-java 1y ago

Some oldschool legends are still fixing bugs in xorg. Alan Coopersmith in particular. He even fixed a bug I reported. :) (I forgot in which app it was but the bug report should be somewhere still; it is not old, perhaps 2 years ago or 3 years ago. The xorg app in question behaved oddly when doing "--version". I only noticed this because I wrote a ruby script that displays which version of programs are installed, and that one kept on making problems, whereas the others worked fine. After I reported it, Alan fixed this very quickly. I think it was some missing flag in the C program or something like that; right now I can not remember the name of the program ... my brain tries to say xrandr but I think it was not xrandr but a less frequently used program somewhere in the FTP listing ...)

ElectroBuffoon 1y ago
Keith Packard, another legend, was proposing X11 improvements in 2018. [0] He doesn't seem to be paid to work in X11 or Wayland, thus being free to float ideas he likes. [0] https://keithp.com/x-ideas/ https://keithp.com/x-ideas/

bitwize 1y ago

These are all "no way to prevent this, say users of only language where this regularly happens" type problems though. The send command in Tk is lel, but can easily be effectively closed by rebinding it to a no-op.