[HN Gopher] X.org Security Advisory: multiple security issues X....
___________________________________________________________________
X.org Security Advisory: multiple security issues X.Org X server
and Xwayland
Author : birdculture
Score : 118 points
Date : 2025-11-02 13:07 UTC (9 hours ago)
(HTM) web link (lists.x.org)
(TXT) w3m dump (lists.x.org)
| rwmj wrote:
| 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.)
| jeroenhd wrote:
| 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 wrote:
| Digging deeper there are mechanisms for long time on internal
| X side (see 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/xse
| rver/d2b60a3d6... )
| lotharcable wrote:
| 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.
| embedding-shape wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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...
| embedding-shape wrote:
| Yeah, assuming all users and all software should work the
| same idea is a great way to get people moving to a new
| platform.
|
| Maybe, just maybe, some people know what they want, and
| if they want applications that can put themselves in
| specific corners, why shouldn't the desktop let the
| applications do that, if the user is OK with it?
| mikkupikku wrote:
| That sort of solution is cancer if you want to do
| anything the display server authors didn't think of. I've
| got a script that I invoke with a global hotkey that
| determines the window title of the currently focused
| window and fuzzy matches it against pipewire audio stream
| names so I can mute the focused window with a single
| keypress. If I want that to work in Wayland I'm pretty
| much up shit creek because somebody with their head in
| the clouds thinks that my needs are super dangerous or
| something.
| justin66 wrote:
| > That sort of solution is cancer if you want to do
| anything the display server authors didn't think of.
|
| Hey come on man, a locking screen saver is a totally
| niche application. No demand for that.
| mikkupikku wrote:
| xscreensaver works just fine. It only needs to keep nosy
| roommates out, not the NSA. Not that Wayland would stop
| spooks anyway.
| udev4096 wrote:
| Totally unrelated, I like your nickname :)
| ethin wrote:
| Wayland devs for the longest time thought implementing
| what was needed for accessibility (mainly, global
| keyboard hooks for Orca to work) was a security problem.
| Nevermind the fact that nobody hacks X servers, or your
| wayland compositor, because if I wanted to hook your
| keyboard with a keylogger, I'd hook it through evdev. And
| then you wouldn't even know let alone be able to do much
| about it if I did it properly.
| array_key_first wrote:
| Wayland doesn't say "this is impossible", it says "this
| is out of scope of the core display protocol, implement
| this somewhere else".
|
| Which, well, we do. Practically all the X usecases are
| covered on Wayland systems now. Screen sharing, screen
| clipping, global hotkeys, file pickers, getting the
| window title like you said... I can do all of that on
| KDE, right now, under Wayland.
| mikkupikku wrote:
| Can you do it in a way that isn't KDE specific, and will
| work if you change your DE one day on a whim?
| tuna74 wrote:
| If you change to another DE that has less capabilities
| than KDE, of course you can't do it. Emacs and
| LibreOffice Writer will have vastly different
| capabilities and people can choose what they want based
| on the capabilities they desire.
| rcxdude wrote:
| That's the issue. Because wayland punts on so much
| functionality that used to be available with standard
| interfaces in X11, it fragments the ecosystem to such a
| degree that all these useful little utilities just don't
| really have a means to grow.
| ethin wrote:
| And that is exactly the problem. Now things like
| accessibility (or, really, any feature that the
| maintainers of the core protocol didn't think were
| "necessary" because they like minimalism) have to be
| implemented by each and every compositor. If the
| compositor doesn't implement it, your screwed unless
| either you convince them to add it or you add it
| yourself. Talk about causing huge amounts of
| fragmentation for absolutely no reason.
|
| The proper thing Wayland should've done is waited until
| Wayland had reached feature parity with X, then released
| it to the world and started acting like it's the future.
| dev_hugepages wrote:
| :(
| tuna74 wrote:
| You can write a Gnome Shell extension or whatever the KDE
| equivalent is.
| uecker wrote:
| 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)
| 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).
|
| 1. 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 wrote:
| > something any good engineering manager should have
| stopped immediately
|
| Who exactly should and can control the horde of OSS
| developers?
| DarkmSparks wrote:
| They were paid by redhat.
| Jasper_ wrote:
| 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).
| uecker wrote:
| I think you did not understand my point. X11 has several
| such mechanisms, yes, but it also has the concept of
| untrusted clients that disallow the use of these
| mechanisms and could be used to provide safety similar to
| Wayland. The point is that this mechanism of untrusted X
| clients was neglected and I gave an explanation way.
| mikkupikku wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| 0xbadcafebee wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| >> 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.
| mikkupikku wrote:
| Using a compositor fixes screen tearing, no need to use
| Wayland for that.
| marmight wrote:
| Even a compositor is unnecessary to fix screen tearing
| these days: https://gitlab.freedesktop.org/xorg/xserver/-
| /merge_requests...
| toast0 wrote:
| X11 has options for tear free video playback; it's not in
| the base protocol, and not all drivers offer it, etc, but
| it's acheivable. Fundamentally, you need to send the next
| frame to the server and ask it to switch frames during
| vblank (+/- notification), on today's systems, this is
| more of a coordination problem than a technical one;
| there's plenty of video ram to go around to
| double/tripple buffer.
|
| HDR would fit in the X11 model of many bit depths,
| however the specifics don't really; afaik, X11 has a
| maximum bitdepth of 32 for pixel values, which means
| either limiting to 2-bits of alpha channel or using
| palettes (I think I saw that indexed colors can be
| defined with 16-bits per channel). An extension might be
| possible (with everything that brings), but I think the
| ship has sailed.
|
| I agree that Wayland's security model prevents some
| undesirable interactions that X11 allows, but it also
| prevents or makes difficult some desirable interactions,
| so it's a mixed bag.
| uyzstvqs wrote:
| Wayland is the way to go. The same applies to Flatpak,
| Pipewire, systemD, etc. I'd say that this is obvious, and
| doesn't even need to be argued, to 99%+ of those who
| actually use the Linux desktop. The only opposition to
| this is a small group of decelerationists with a major,
| irrational aversion to change.
| mx7zysuj4xew wrote:
| Everything you listed is bloated, slow, incompatible,
| unfinished or unstable. My system worked fine 20 years
| ago on far less capable hardware. Now even with high end
| workstations systems lag, crash or have strange behavior
| zdragnar wrote:
| > What's insane about all these discussions is that NOBODY
| IS HACKING X SERVERS
|
| I knew someone who worked for a small loan type company.
| Passwords were stored in plain text, but even worse, the
| login form didn't actually check the password at all, it
| created valid sessions as long as you provided a valid user
| name.
|
| When he informed his boss that was very bad, his boss
| simply said that nobody has abused it, and nobody would,
| don't waste time changing it.
|
| The point, of course, is why would you wait until people
| are getting hacked to address a known vulnerability?
|
| Sure, there are others, and they should be closed too, and
| they are when they are found. It makes no sense whatsoever
| to leave one open just because.
| portaouflop wrote:
| It does make sense if the vuln doesn't fit in your threat
| model. There are always an uncountable number of
| vulnerabilities and you can never fix all that are found.
|
| No idea of course if the threat model that said boss had
| in mind made sense. But I always recommend to come up
| with a reasonable threat model first and then think you
| can harden against it.
| nurettin wrote:
| I don't dispute your anecdote but I think the point was:
| x11 has been around for decades, and these things just
| don't happen. And the reason is that there are much
| simpler and more effective ways to pwn a box than trying
| to screenshot an x session or trying to hook for key
| presses. So the vulnerability surface just isn't large
| enough.
| themafia wrote:
| > is why would you wait until people are getting hacked
| to address a known vulnerability?
|
| Do you have some other way of _reliably_ identifying
| vulnerabilities?
|
| > It makes no sense whatsoever to leave one open just
| because.
|
| It makes sense to have security options. If I want to
| leave it fully unlocked, that's my business, and I
| possibly have good environmental reasons to do this.
|
| What you should really care about are security
| _defaults_. And in X11's case I'm not aware of any
| distribution that ships the server with TCP connections
| to the sever enabled. You have to go well out of your way
| to even begin using this functionality.
| da_chicken wrote:
| I think the point being made isn't that X.org shouldn't
| fix their vulnerabilities. It's that there's always a
| huge amount of discussion about vulnerabilities and
| security models when one is found in the display server
| or the window manager when actual exploitation doesn't
| seem to be particularly high.
|
| Many distros, if not most distros, disable port 6000+
| listening for X.org by default. So, immediately, it's not
| a remote exploit. OK, so it's scope is already limited to
| local escalation attacks. Looking at the CVE, the only
| reason it's high is because (a) X.org is everywhere, (b)
| you don't need to interact with [another] user to exploit
| it, and (c) it's not particularly complex to exploit.
|
| That is bad, but it's also _behind_ most of the other
| security, rather than bypassing essentially all of it
| like Heartbleed or Shellshock.
|
| So, either I have to have X forwarding turned back on, or
| have people with SSH access to a server that is also
| running X. Both of those seem like uncommon situations.
| You probably shouldn't be running X or permitting X to be
| started unless you need X forwarding, and X forwarding is
| a pretty odd requirement given modern application design
| being so web-browser-focused.
|
| So it might be CVE High 7+ if you're on a system where
| it's possible to exploit it. But it feels like you
| shouldn't often be on a system configured in a way where
| it _could_ be exploited _in spite of the prevalence of
| X_.
|
| Essentially: This isn't a rehash of the libXfont problem.
| jchw wrote:
| > 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 incidentally run within a typical graphical
| user session will have access to the X socket and a cookie,
| they _will_ be able to connect. And after they connect...
| They basically just can do anything they want with zero
| real restrictions, including most likely some fairly
| trivial paths to root escalation. Even if they 're running
| inside of a sandbox or container, with only an X11 socket
| poking through.
|
| This problem was realized a very long time ago with the
| security extension but most of it never really caught on.
|
| > 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.
|
| If you believe this is true, then what exactly is the point
| of _any_ security measure? Why bother using isolation and
| sandboxing, or passwords? Why does Windows bother patching
| flaws if they know there are certainly more of them and
| they will never fix them?
|
| Do you by chance also smoke because you're going to die
| anyways?
|
| > 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.
|
| Lol. That's primarily because the Linux desktop is utterly
| irrelevant, not because nobody would care to do it. Is it
| really surprising that attacks against desktop computers
| would focus almost entirely on the OS that has 90+% of the
| market share? We don't get free software OS desktop malware
| for the same reason we don't get free software OS software
| ports.
|
| Watching and waiting with security was a totally acceptable
| position in the 90s, but we get the general gist these
| days. We need security-by-design.
|
| On the server side of Linux where Linux is relevant, the
| situation is much more impressive; auditing using eBPF,
| sandboxing with gVisor, microVMs with Firecracker and
| cloud-hypervisor, isolation using namespaces and seccomp-
| bpf and more.
|
| On the desktop side, people are still arguing over whether
| or not it's a problem that any X client can by default
| silently keylog the entire system trivially. Okay, but a
| lot of us actually see that as a problem, and we're not
| interested much in "hearing you out". Most of us recognize
| that the Wayland protocol has warts (and too many damn
| protocols), but X11 has many more warts. I didn't care what
| was the successor to X11 specifically, I just cared that we
| eventually made _some_ progress. Most people have nothing
| to offer here and just suggest we should 've stuck with
| X11. Okay dude, but nobody wants to. The X.org devs would
| like to move on. The desktop environments really would like
| to move on. There was basically one serious guy that
| actually wanted to work on improving X11 and he turned out
| to be kind of crazy and couldn't stop breaking shit
| anyways.
| zzo38computer wrote:
| You could use a proxy server (regardless of the
| protocol), which might improve security (and other
| things) better than other methods do, I think.
|
| There are problems with both X11 and Wayland, although I
| dislike some of the features of Wayland.
| jchw wrote:
| Yeah, with Qubes that's exactly what they do. I forget
| what the software is called, but they use an X11 proxy
| that tries to enforce policy.
|
| That said though, that does require you to proactively
| run every X application with this sandboxing. For Qubes
| which forces everything into VMs this is doable, but for
| most other systems there isn't an obvious way to handle
| this sort of thing.
|
| My only major complaint about Wayland that can't just be
| fixed relatively easily is Mutter refusing to support
| SSD. (Well, the actual technical problem could be fixed
| relatively easily, but the social one not so much.)
| fpoling wrote:
| Firejail uses nested X11 servers like xeohyr or xrdp to
| restrict application access to the primary X11.
| jchw wrote:
| Hmm, I thought it was Xephyr but I was wrong. It looks
| like Qubes actually does something even more involved:
|
| https://doc.qubes-
| os.org/en/latest/developer/system/gui.html
|
| This makes sense though, given the way clipboard works in
| Qubes. I think I must've entirely mistaken how Qubes
| works for an entirely different scheme.
| jeroenhd wrote:
| Of course X has authentication, but once you're in, you're
| in. There are no elevated windows, screen recording
| permissions, or any sort of keylogger prevention. That was
| normal a few decades ago, but the world has moved on since.
|
| There's no real reason it can't do any of that, it just
| doesn't and there are no real plans to add these features.
|
| I'm not convinced by the "if you run a program you should
| assume you've already been hit by a CIA 0day". Obviously
| nobody is dialing into your X11 server from the internet,
| but this is a relatively easy nobody:nobody -> root/wm-
| session/whatever elevation of privilege.
| udev4096 wrote:
| Any application can literally log EVERYTHING! It's good to
| see wayland getting better everyday
| exasperaited wrote:
| > 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.
| shevy-java wrote:
| 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 ...)
| samtheprogram wrote:
| Would Fil-C have prevented the first or third?
| dingdingdang wrote:
| Wonder how these play out against the
| https://github.com/X11Libre/xserver base, would be interesting to
| hear from that end as to how these things are handled. My
| understanding is that they address any sec issues that arise on
| x.org but it would be fascinating if the issues are already
| mitigated since XLibre updated their xserver port with 1000s of
| issues that were never addressed on the x.org side of things.
| richard_todd wrote:
| On their github you can see all three changes identical to
| x.org's happened on October 28th (same day as the advisory).
| So, they were not already fixed, but the fixes were applied
| immediately.
| throw83940404 wrote:
| This project has way more serious problem than security!
| kevin_thibedeau wrote:
| Coverity is pretty good about finding these kinds of bugs. Is
| there a reason why a project as significant as Xorg isn't taking
| advantage of their gratis access for that tool?
| josteink wrote:
| I think the short story is that the people who develop Wayland
| are the people who used to develop Xorg.
|
| And they'd rather spend their energy on giving you a compelling
| reason to switch, rather than using it to add to the reasons
| for staying on a project they now consider obsolete.
|
| You may disagree with their assessment, but you can't blame
| them for how they decide to prioritize.
| shevy-java wrote:
| Don't kill xorg! :(
___________________________________________________________________
(page generated 2025-11-02 23:00 UTC)