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.