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

▲

da_chicken 5 days ago | parent | next [-]

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.

▲

immibis 4 days ago | parent | next [-]

This is because Wayland wants to differentiate itself from X on security. Wayland has to show it's more secure than X - as part of that, Wayland has to show that X is insecure.

▲

jonway 4 days ago | parent [-]

No, wayland already differentiates itsself from X11 because X is a tool for graphical network terminals and Wayland is a tool for single machine rendering.

X11 is a mountain of tech debt that almost nobody wants to maintain.

▲

4 days ago | parent | next [-]

[deleted]

▲

theodric 4 days ago | parent | prev [-]

Wayland is what you get when you decide to start a space program because, let's be honest, the electrical gremlins in your 1983 Mercedes 560SL are beyond properly fixing, and the kids still need to get to school

▲

jonway 4 days ago | parent [-]

X is equivalent to calling your spouse on the telephone when they are sitting next to you on the couch.

	▲	immibis 4 days ago \| parent \| next [-]
		How do shared memory and unix sockets fit into this analogy?
	▲	theodric 4 days ago \| parent \| prev [-]
		whomst among us

▲

0xbadcafebee 5 days ago | parent | prev [-]

But there is no vulnerability at all. For a normally configured X server with TCP listening, the server should be configured to use MIT magic cookies for authentication. This randomly-generated string is needed to authenticate and establish a connection to the X server. You can use the xauth command to manually configure it as needed.

It's the equivalent of HTTP Digest authentication, and nobody's demanding that we rewrite HTTP because Digest authentication. It's in plaintext, so you shouldn't use it; but if a hacker doesn't know the secret, they can't get in.

	▲	da_chicken 5 days ago \| parent \| next [-]
		> But there is no vulnerability at all. For a normally configured X server with TCP listening, the server should be configured to use MIT magic cookies for authentication. This feels like you're not understanding why something is called a vulnerability, how they're defined, or why they get rated the way they do. "It's not vulnerable in a best practice configuration," is not the same thing as, "there is no vulnerability." That is incorrect and misleading, and I think you're conflating risk and severity. The definition used for a vulnerability is [0]: "A weakness in the computational logic (e.g., code) found in software and hardware components that, when exploited, results in a negative impact to confidentiality, integrity, or availability." (emphasis mine) The CVSS score is not a measure of risk. It is a measure based on the qualities of the defect that was identified and how widespread the software is. A higher CVSS score is associated with higher risk, but your risk is going to vary based on your configuration. All they did was go to the calculator[1], plug in the answers that best fit the definitions provided for what those areas and responses mean (e.g., CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H for CVE-2025-62229), and they get that 7.3 score [2]. [0]: https://nvd.nist.gov/vuln [1]: https://www.first.org/cvss/calculator/3-1 [2]: https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:L/AC:L...
	▲	hirako2000 5 days ago \| parent \| prev [-]
		Digest as I understand it is a weak authentication protocol, it doesn't mean it is implemented with known vulnerabilities. I distinguish vulnerability from weak. The weakness is not necessarily intended, but the question is, does it do what it is supposed to do. Or is there a known bug: non intended possible exploit, that would make it a vulnerability. If it isn't known then it doesn't exist. But we can assume all software do have bugs. Digest is part of the http protocol, if the protocol is found to have vulnerability I can imagine it would be dropped and be rewritten. The digest part, not the entire http protocol. A hacker may not have the password, but manages to brute forces it. Is that a digest vulnerability or does it fall onto the application to integrate some preventing brute force authentication measures? My take is digest doesn't pretend to prevent brute force attacks. Some may not agree with that logic, but since about everything is made of a combination of vectors, and that each typically has some weakness, all you get is a balance between usability, cost, and security. We can make the case for your typical cryptographic signature, or encryption algorithm. ECDSA standing as well respected, solid cipher. Is it vulnerable? It is vulnerable to the potential power of machines we may build in times to come. Quantum or leaps ahead. Will it be vulnerable then? Yes but it isn't a vulnerability. We would then call ECDSA obsolete. Digest is obsolete yes. The interesting part about cryptographic methods is that we may know of some being obsolete ahead of time. So long as we can determine they can be brute forced. For now it isn't obsolete despite the existence of quantum resistant alternatives. Hacker news uses ECDSA for the exchange of keys between server and client, then encrypts all connections using another algorithm safe against quantum computers. Thanks. But beyond that, probably not. Is X obsolete? Vulnerable? Seems like X developers themselves admit it is a vulnerability. They didn't know of the possible exploit. As to the severity? It's often subjective from my experience. Happy to be wrong, and we don't have to agree.

▲

nurettin 5 days ago | parent | prev | next [-]

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.

▲

Suzuran 4 days ago | parent | next [-]

That's not how this works. If you cannot prove conclusively that something is not the case ever, then you must accept that somewhere in the infinity of possibility it is.

▲

kragen 5 days ago | parent | prev [-]

I have definitely seen "these things" happen.

▲

nurettin 5 days ago | parent | next [-]

What did you see specifically? And on what OS?

▲

41throw-it 4 days ago | parent | next [-]

Hi -- throwaway

I have seen this happen as well. A memory corruption vulnerability in popular software allows unpriv shellcode to reach out and drop a rootkit which loads a rat as a kernel module. Attacker has control. Several big problems.

cobaltstrike beacons blocked. Instead pierce nat with STUN to attacker proxy. Use socket activated VNC/RDP/X.

Why not just steal the sessions and local data? Remote services log access (ip, time, location), easily correlate and forensics would lead back. Local data encrypted at rest, hands on keyboard needed any way since recon incomplete. Are they planning to scan memory for ssh key unlocks or intercept ssh -sk key? This is big, noisy and take developer time. If you log in to a email this leave forensics and is a CFAA violation while risking FAANG security. Attacker needs to shoulder surf.

Most hack is install crypto mining or steal a password. Maybe it is ransom. How do you get 2fa code if you want access to sensitive information? How do you steal hardware keys? You can back door browser, MitB but it gets updated away and you lose access. back door anything and lose access or discovered.

This is not a advanced attacks but it is targeted attacks. People are saying x server never get hacked, but computers get hacked. with X11 the chain is Exploit -> Game over. with wayland you need to go farther.

▲

anthk 4 days ago | parent | prev | next [-]

All of NIXen.

~/.profile

~/.env

~/.xprofile

Exploiting TMPDIR, /tmp race conditions, ~/.mailcap and mutt (I used that to get access to 'premium' binaries under restricted accounts).

If you have Emacs you can do tons of stuff from a single account.

And so on.

▲

nurettin 4 days ago | parent [-]

Not sure what mutt has to do with X. Maybe you replied to the wrong thread.

	▲	41throw-it 4 days ago \| parent [-]
		~/.xprofile I agree in a little way to what you say, but if you can write .xprofile you can with no work escalate from the x socket.

▲

kragen 5 days ago | parent | prev [-]

Can't give details.

▲

LtWorf 5 days ago | parent | prev [-]

Source?

▲

kragen 5 days ago | parent [-]

No, I've seen them. Myself. I didn't get this from a source.

▲

LtWorf 4 days ago | parent [-]

So you didn't report the bugs?

▲

kragen 2 days ago | parent [-]

No bugs were involved, just X11 functioning as designed.

▲

LtWorf 2 days ago | parent [-]

So you just don't like X11. Ok. But what was your point then other than share your personal feelings?

	▲	kragen a day ago \| parent [-]
		It sounds like you're out of your depth in this conversation, Lieutenant. I have ambivalent feelings about X11, but they aren't relevant to the topic at hand. 0xbadcafebee said, "Why do people keep persisting this myth? X11 has authentication. ... 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 ..." and then nurettin followed up by saying, "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." But in fact I have seen people gaining elevated privileges by "hijacking" X servers when the authentication was configured to be lax, and I've sometimes configured my own authentication to be lax (because configuring it properly was a hassle), so I know it's not an "imagined threat" from "NOBODY" or a "myth" or things that "just don't happen" because "nobody is trying" them. But it's not a "bug" either. It's a design tradeoff. X just wasn't designed to provide a security boundary between applications, to encrypt its network traffic, or by default to use any authentication at all other than host-based authentication. Even MIT-MAGIC-COOKIE-1 auth was an add-on, and it is sent in the clear, permitting replay attacks. These are defensible tradeoffs, and ssh -X and the current xauth defaults improve the situation significantly, but Wayland's design provides a lot more isolation between applications by default, which is probably a more defensible tradeoff.

▲

themafia 5 days ago | parent | prev | next [-]

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

▲

zahlman 4 days ago | parent [-]

> Do you have some other way of _reliably_ identifying vulnerabilities?

This is irrelevant given that we are talking about known vulnerabilities.

No, you can't reliably find all the vulnerabilities by auditing the code.

Yes, if you audit the code and believe you have found a vulnerability, you fairly reliably are correct in your belief. And should probably take action even if you aren't.

	▲	themafia 4 days ago \| parent [-]
		> we are talking about known vulnerabilities. In a context which does not involve them. I simply ignored the subtle goalpost shift and addressed the core issue of the article. > And should probably take action even if you aren't. Where they action could include "disabling as a default option." Yes?

▲

portaouflop 5 days ago | parent | prev [-]

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.