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.
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.
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?
~/.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.
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.
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.
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.
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.
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.
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.
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...
X11 is a mountain of tech debt that almost nobody wants to maintain.
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.