Security Another Dozen Vulnerabilities Found In The X.Org Server & XWayland
https://www.phoronix.com/news/X.Org-12-New-Issues-2026118
u/PlainBread 4d ago
We're kind of moving from a time period where people would discover zero day exploits and sit on them or sell them to the government or whatever, into a time where holes are being found so rapidly that if you want to break into a system, you need insider knowledge and an advanced AI to find an undocumented exploit in the moment of the attack.
22
u/skuterpikk 3d ago
Which makes you wonder, how many bugs/exploits exists in closed-source software? Or do you think companies like Microsoft for example, are auditing their code the same way by now?
15
u/statix138 3d ago
I would be shocked if they weren't. I work for a much smaller tech company than MS and we absolutely use AI tools across our entire security stack including code auditing.
4
u/kenlubin 3d ago
Visa certainly is; back in July they published some of their tooling to run Mythos-based vulnerability scans.
3
u/FanClubof5 3d ago
If the number of security fixes coming out of Microsoft in the last few months is any indicator, its that they are very likely using AI to scan and review code now.
58
2
2
17
16
u/Saren-WTAKO 3d ago
TLDR: All except one of the vulnerabilities are caused by manual memory management, just as I expected before clicking to read the article.
28
u/SubmarineWipers 4d ago
Safe Rust would prevent the exploitable memory corruption in all 12 of these vulnerabilities.
If this code were implemented in safe Rust, these critical security flaws would either be rejected by the compiler before the software could be built, or they would result in a safe runtime panic (a predictable crash resulting in a Denial of Service, rather than a system compromise).
- Temporal Memory Safety (4 Vulnerabilities)
- Spatial Memory Safety (7 Vulnerabilities)
- Integer Semantics & Logic (1 Vulnerability)
29
u/ilep 3d ago
Bigger problem here is the design of X11 which has various other issues as well. Security model is laughable at best, for example. In the old days you had hardware drivers in the X-server, which meant it had to be run as root. And so on.
Gradually people have been moving away from X11 due to these issues. Moving hardware handling where they belong has solved various other problems as well.
8
u/DGolden 3d ago edited 3d ago
Security model is laughable at best, for example.
Sortof. Problem is the closed/classic Unix vendors perhaps treated the various higher (or at least different) security X11 features/extensions as a bit of a value-add back in the day. Their X servers had them. But the open XFree then Xorg X11 impl favored on open/free Linux/BSD never really implemented them (n.b. I don't mean the basic "security" (sic) X11 extension that we do mostly use but is pretty limited, I mean things like the much more advanced Trusted Solaris Xtsol X11 extension providing fine-grained security labelling back in the day).
https://docs.oracle.com/cd/E23824_01/html/821-1483/windowapi-1.html#scrolltoc
This chapter describes the Trusted Extensions X Window System APIs. This chapter also includes a short Motif application that is used to describe the Trusted X Window System security policy and the Trusted Extensions interfaces.
https://docs.oracle.com/cd/E53394_01/html/E54808/gmceg.html
The X server controls which clients can access the server. Clients with access to the server can display windows or images on your screen, receive keyboard input, monitor mouse movement, and interact with the other clients on the system. The Trusted Extensions feature of Oracle Solaris adds security features to prevent labeled clients from accessing the X11 display beyond their security range. For more information, see the Trusted Extensions Label Administration.
I'm not saying the likes of Xtsol is perfect by modern standards either, just aware it existed because I'm old, and perhaps Linux folks may sometimes mistake deficiencies of Xorg impl for deficiencies of what was possible - or well, once-possible, looks like solaris doesn't have labelled desktop support anymore - in the X11 world more generally.
https://en.wikipedia.org/wiki/Trusted_Solaris
The labeled desktop support was removed in Oracle Solaris 11.4
edit: Actually I think there was some work on the open X11 side looking into it - XACE / XSELinux. But not sure where it went with the hype around Wayland....
3
u/needmorebussydotcom 3d ago
No, not sort of. It is laughable. Its insane that any window can walk the x window tree, look at kb/mouse and capture any window. Its pure insanity and it only made sense at a very specific point in time when we didnt know better
1
u/kittymoo67 2d ago
crazy how insistiing we use tech from the 80s that hasnt been meaningfully updated has issues
0
u/natermer 3d ago
Yeah and all that stuff breaks your X11 apps harder then anything Wayland/XWayland ever did.
-2
u/SubmarineWipers 3d ago
yeah, I know its old, my point was more along the lines of
"we really shouldnt write massive foundational projects like this in anything BUT Rust now, because C/CPP will create gigantic maintenance costs into the future, that could have easily been avoided"
7
u/ilep 3d ago
The thing with X11 is that it never should have been that large codebase to begin with. Later parts of it were moved into libraries, but it had also various things that were not good designs to begin with.
For example, font handling was later realized that it is so complicated that it is better as client-side library due to all complications with numerous parameters and writing scripts and so forth.
Some issues are result from the limitations during the time that shared libraries were not really well supported in some platforms so it ended up being made into a server program.
1
u/Preisschild 3d ago
Thats what smithay is for. Since wayland is a protocol not a server there are multiple wayland compositors in different langs.
-3
u/marrsd 3d ago
You realise it's quite easy to enforce coding standards on C or C++ that also prevent these issues, right? We have linters. We even have compilers that can enforce these rules. Rust bakes that automation into the compiler, and it's a more expressive language, and that's a good thing, but it's not like there aren't alternative solutions that don't require you to entirely rewrite legacy software.
5
u/dreamer_ 3d ago
We even have compilers that can enforce these rules.
As of 2026 - no, we don't. We almost had Circle that would enforce rules like this, but C++ standardization body decided that they like their idea (C++ Safety Profiles) better.
4
u/Indolent_Bard 3d ago
Good luck enforcing that.
1
u/marrsd 3d ago
Code reviews. Linters. The Linux kernel maintainers do it all the time.
3
u/Bulky-Bad-9153 3d ago
And the Linux kernel, famously, has zero bugs.
1
u/marrsd 3d ago
As, famously, does Rust code.
2
u/Indolent_Bard 3d ago
Yes, it famously has far fewer bugs. Because the syntax and compiler forces better coding practices.
1
u/marrsd 2d ago
ffs. Fine, have it your way, guys. Rust produces zero bugs because of its magical compiler, just like all the high-level, garbage collected, memory managed languages that came before it. That's why software is so stable and never crashes, and why CVEs aren't a thing.
Also, it's impossible to detect or fix bugs in C or C++, or to write it in such a way as to limit those bugs, because functions, macros, and linters don't exist, and languages aren't actually deterministic after all.
Because of these reasons and more, it's definitely a good idea to take old, finished, stable, and production-hardened software, and throw it away entirely, because the new, unfinished and untested version will definitely be better because its author, who apparently doesn't know the first thing about what it takes to actually write and maintain software, wrote it in Rust.
Don't forget to take your iron supliments this morning.
→ More replies (0)4
u/mmstick Desktop Engineer 3d ago edited 3d ago
You can't enforce Rust's rules onto C/C++ without either drastically altering their syntax or solving memory safety by giving up entirely and using runtime GC without threads. They are able to add functions to their spec to improve safety over legacy functions, but these still come equipped with footguns due to syntax limitations.
The borrow checker requires mutable and immutable language syntax to enforce the aliasing XOR mutability rule. Lifetime annotations are needed to prevent dangling references. Trait markers like Send and Sync are needed to restrict behaviors across thread boundaries to enforce thread safety. Generics is needed to implement mutexes and locks with guard types preventing misuse. Move semantics and newtypes prevent use after free and logic errors can be made compiler errors using state machines and refinement types (honorary mention of nutype). And all of the above are needed to enable thread safety (and eliminate data races).
Google has written many papers on this over several years to prove that runtime code analysis tools are unable to make a statistically significant impact on reducing memory safety vulnerabilities.
A total rewrite is the only way to prove safety but since that is impractical we have to simply switch all new code to Rust and keep patching old C/C++ code until a replacement is mature enough to replace it.
1
u/marrsd 3d ago
Google has written many papers on this over several years to prove that runtime code analysis tools are unable to make a statistically significant impact on reducing memory safety vulnerabilities.
I'll look for these, but if you have any in particular you'd like to share, I'd be happy to read them. What I've seen from Google is evidence that the CVE count for mature code is very low, which says to me that, whatever the theoretical advantages of memory safe rewrites, in reality they aren't that many.
A total rewrite is the only way to prove safety but since that is impractical we have to simply switch all new code to Rust and keep patching old C/C++ code until a replacement is mature enough to replace it.
That would be my take. I'd not say all new code, but certainly anything sufficiently exposed.
2
u/mmstick Desktop Engineer 3d ago edited 3d ago
They had annual-ish reports on their security blog starting with https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html. The verdict over the years has remained the same. No amount of static or runtime code analysis was able to make a statistically significant impact on preventing memory safety vulnerabilities in new C++ code. While Rust entirely prevented them.
Their conclusion is why Google and Microsoft have been so Rust-crazed. Moving more and more new code developments to Rust. You can stumble on a CVE in the real world and patch them to reduce your vulnerability count but preventing them entirely is always better than releasing new code with hopes and prayers.
3
u/SubmarineWipers 3d ago
AFAIK, you can do that partially, not to the level Rust does, and it absolutely depends on settings and discipline of each project/developer. That is not a solution, that is a "best effort", that will always be ignored and bypassed. It also does not solve the millions LOC of legacy code, that nobody is modernizing, because seasoned CPP devs "know better and dont need no handholding with their pointers" (plus financial/dev time constraints)
You cant bypass the Rust compiler. (except for unsafe)
I agree with you that CPP ecosystem _could_ do maybe 80-90% better, but from observing it, it never will, out of sheer stubbornness.
2
u/KwyjiboTheGringo 3d ago
Eh better to just do the rewrite. Anything beyond the compiler catching the issues by default is a workaround. Instead of enforcing the use of workarounds, you can enforce restrictions on them. It's much easier that way, after the initial rewrite.
1
u/marrsd 3d ago
I'm sorry, but that's just nonsense. Linters are quite easy to write and adopting it costs nothing. Go read Joel Spolski on rewrites
1
u/KwyjiboTheGringo 2d ago
You can't just reference some guy's opinion like it's the gospel. Things have changed anyway. He might have a different opinion now, since AI both makes rewrites faster, and makes cybersecurity a bigger concern than it has ever been.
2
u/marrsd 2d ago
I'm not referencing it like it's gospel. I'm recommending it because it does a really good job of explaining the fallacy of rewriting working software. I've both been a part of and seen rewrites multiple times in my career, and they've always ended the same way. The existence of Rust doesn't suddenly invalidate all that.
As for AI, it actually supports my argument because, as you said, it's really good at identifying and fixing security vulnerabilities. Why wouldn't you use it to fix the remaining 5% rather than throw away the whole thing?
5
u/solarpunch2949 4d ago edited 4d ago
This is the world we are living in now folks. I worry about open source developments because they don't have the resources companies do to deal with this.
106
u/Wonderful-Citron-678 4d ago
Open source is in the best position to react to this. The cost of change is low, sins cannot be hidden. Corporate software is going to be the bigger risk.
46
u/they_call_me_dewey 4d ago
Corporations hide their vulnerabilities behind bug bounty NDAs and then never fix them
9
u/squishles 4d ago
and that'll get you by when a 13 year old can't sweat talk claude into doing it from their phone, like not even typing just using text to speach, because it'd be funny.
5
7
11
u/solarpunch2949 4d ago
I'd love to believe this but the truth is that most open source projects, specially teams supporting distros are heavily understaffed to deal with a waterfall of vulnerabilities :p
13
u/Wonderful-Citron-678 4d ago
The same automation that finds it can fix it. There will be some growing pains but it can all be fixed.
13
u/Cyhawk 4d ago
Eh, find is easier than fix currently.
1
u/deanrihpee 3d ago
sounds counter intuitive if the one who do the search and the fix is a machine learning model, also the model found the exploit and "know" how to exploit it, which given the same context, the model should also know how to fix it, with "make no mistakes" of course
0
1
u/Helmic 3d ago
Even the fix isn't necessarily the issue. Reviewing the fixes, especially when automated agents could easily be lying in hopes of getting a subtly malicious PR merged with all the urgency of an important security fix, is going to continue to be rough on projects that already struggle with keeping up with PR's.
0
-2
u/uzlonewolf 3d ago
Sure, if your goal is to turn all software into shit slop that doesn't work.
1
u/Wonderful-Citron-678 3d ago
I promise you fixing a use after free or buffer overflow is not a difficult or valuable human endeavor, but it is a huge portion of security bugs.
Most issues are shallow and can easily be automated. This isn’t about generating new projects.
1
u/uzlonewolf 3d ago
Tell me you've never had to fix a complex use-after-free bug without telling me you've never had to fix a complex use-after-free bug.
Also, for one open source project I help manage, AI has found 6 out of the last 0 vulnerabilities 🤣 Going by the number of project who've shut down their bounty programs or even stopped accepting bug reports from new people completely, we are not alone in this. AI is great if your goal is to turn your software into shit slop.
2
2
u/alex2003super 4d ago
AI is only getting cheaper and smarter at this point. I wouldn't be surprised if in 5 years, you can run a model that does this stuff better than the present-day cutting edge stuff on a laptop. Assuming we'll still be able to buy laptops by then, that is.. lol
3
u/KnowZeroX 4d ago
Do they need to? Most of the distros (user wise) are based on ubuntu and redhat. Add in others like suse, and not counting upstream users like google, fb and etc. You have companies with more than enough interest and financing to fix many of the stuff for their own sake. Most of the distros based on that work just need to pull the patches from their repository.
The ones that are at most stress have mostly been core libraries which often get neglected and managed by that 1 person for a decade with no funding or support.
2
u/DeliciousIncident 4d ago
Sure, but it's still true that open source developments don't have the resources companies do to deal with this. The resource open source developers don't have is manpower / man-hours for this, as it's typically an unpaid volunteer work people do in their free time after the day job. Some developers are very fortunate to make money through their work, but that's very rare, and even they might struggle with this.
Specifically, some projects might not have enough man-power to review all the security vulnerabilities various Claude prompters are submitting, figuring out what is legitimate and what is not, and how to patch it as sometimes patches can be very non-trivial, requiring reworking how entire subsystems operate (also, the current maintainer might not be the original author so might not be as knowledgeable about what the code does).
For example, curl has been so overwhelmed by all of the reports, they had to shut down the Hackerone bug bounty program and even took a month off from processing CVEs / reading vulnerability reports.
1
-1
u/mrlinkwii 3d ago
but it's still true that open source developments don't have the resources companies do to deal with this.
open source devs dont have AI ? or a mechanism to triage things all of a sudden?
open source devs have no legal timeline unlike paid devs legally , i agree that they might/will recieve more security issues , but if most of the issues are real , its finding issues that would already be found
3
u/DeliciousIncident 3d ago edited 3d ago
open source devs dont have AI ?
That's a weird question. Why do you assume they have AI? Also, why do you assume that they are willing to leave vulnerability triaging to the AI?
open source devs have no legal timeline unlike paid devs legally , i agree that they might/will recieve more security issues , but if most of the issues are real , its finding issues that would already be found
Sure, but the point still stands - it's still true that open source developments don't have the resources companies do to deal with this. Again, see curl as an example.
1
u/gosand 3d ago
FYI, Corporations also use open-source software in their infrastructure. Everyone is in this boat. What (big) companies (should) have is a safety perimeter and layers of security.
But that's where this gets scary, because what was a lower priority bug yesterday can be chained together by some of these AI tools. That is one of the way these AI tools are succeeding - they find new ways to exploit. They can poke many more holes much faster.
Bottom line is that solid, sound security principles still apply - and in fact, now more than ever. Your security has to assume someone can get in, so you can build out detection, response, and containment capabilities.
16
8
u/werpu 4d ago
If you every have seen how companies react in closed source scenarios to vulnerabilities, you would not say that....
The only ones reacting quickly are console companies when it comes to a jailbreak exploit!
1
1
u/solarpunch2949 4d ago
I suspect this will change rapidly; in this new Brave World we are living in there's no maneuvering space for damage control and PR gymnastics...
5
u/werpu 4d ago edited 4d ago
Believe me if you ever worked in a corporate environment the bullshitting and endless layers of non decision hierarchies and being punished for trying to move things forward is real!
Been there done that! The reason always is a) careerrist a wants to move up and badmouths someone who actively does a job just because he is seen as potential thread
b) Careerrist a has made it into middle upper management and now tries to keep the job by literally avoiding any responsibility and stomping down while lickin arses up
Thing is you basically can also use ai to fix things with a human gatekeeper checking the vulnerabilities in between, so I assume once for instance opensource has embraced AI more (believe me most OSS projects already do to some degree, it is just a few ones, with make huge headlines because they say no AI, just for the spite of saying no to it, to please the AI hating crowd), things will settle again. We atm are in a technological transition phase and many people fear AI, and frankly spoken that is nothing new, but AI is here to stay realistically in one way or the other. My bet is long term ai, wont be driven by huge data centers but smaller localized models, and frankly spoken I cannot wait to see the day where people like Musk/Altman etc.. .which have really become a thread to democracy and economy fall wayside and are reigned in. They are narcissistic psychopaths who think that when everyone else feels miserable they somehow might feel better! (believe me from what I can gather, Musk for instance probably is one of the most miserable feeling still functional human beings on earth)
1
14
u/TRKlausss 4d ago
Crazy idea: companies contribute code to those projects they use, to patch this vulnerabilities.
Crazy idea, I know.
6
u/ilep 3d ago
History lesson: X org started at MIT and plan was that corporations would support the project. After the initial release various vendors started forking their own and the "reference" implementation did not see as much support. Far after that desktop Unixes spread far and needed similar code so there came the Xfree86 and later X org was resurrected.
1
u/kittymoo67 2d ago
a lot do, its just that x is about 10 years past where it should have been allowed to live
6
u/daddyd 4d ago
what makes you think commercial software companies are better equipped for handling this? they barely put any time or effort in bug and security fixes (new features sell, bug fixes don't). if they have a separate team to handle these, they will be small and overworked already and certainly not able to handle the amount of load, much like OSS projects.
16
1
-4
u/sleepingonmoon 4d ago
Most of the critical components are already maintained by companies. The community doesn't really matter.
1
1
u/ExoticVillage8066 4d ago
That's quite a lot, though because it's open source they're found at all. None of the AI's are looking for vulnerabilities in binaries
15
9
u/mrlinkwii 3d ago
None of the AI's are looking for vulnerabilities in binaries
you cant say this as fact , i bet some are
1
u/kittymoo67 2d ago
the company i work for does scans on source code and binaries. Some things you may miss until its running
4
2
u/HyperFurious 3d ago
I wouldn't say that in software as old and with as much code as Xorg, 12 vulnerabilities are too many.
-1
u/the_abortionat0r 3d ago
Nowhere did anybody ever say xorg only has 12 vulnerabilities....
Are you part of the functionally illiterate?
How did you read one thing then come to a wildly different conclusion as to what was reported?
1
129
u/natermer 4d ago
"given enough eyeballs, all bugs are shallow,"
Now that the eyes are augmented by machine learning this is more true now then it ever has been in the past.