X.Org Server Hit By New Local Privilege Escalation Vulnerability

[ryao]

Something similar happens to log4j, they did not get enoguh maintenance because everybody thought they are mature code and there's nothing that can go wrong.

So being mature doesn't mean it is necessary better, the code could be in a mess and nobody has enough time/effort to fix them, despite them seemly to "function as normal" until you discover it is malfunctioning.

These are called outliers in statistics. Anyway, mature code is in general better than immature code. If you want to replace mature code with something that has yet to mature, you are going to have pain until the replacement matures. That is how things work and it is true regardless of how much you want to hear otherwise.

As for security bugs, those happen with just about anything that has an attack surface. Without doing formal verification, security bugs in software is practically a certainty, no matter what the developers do.

[NobodyXu]

These are called outliers in statistics. Anyway, mature code is in general better than immature code.

There are certainly outliers, but I'm not so sure these examples I mentioned are outliers as they are extremely popular projects used everywhere.
If they are not getting enough maintenance, then there are certainly a lot other projects not getting enough maintenance but used a lot and is considered as "mature code"/

If you want to replace mature code, you are going to have pain until the replacement matures. That is how things work and it is true regardless of how much you want to hear otherwise.

Of course you won't switch to the replacement right away until you are confident that it is correct and is better.

[Siuoq]

Well in this instance it is the "mature" code that has security issues. Besides what you say isn't necessarily true, it all depends on what assumptions (if any) regarding security were made when the respective codebase were developed, and how they relate to present security threats.

Have you read the article? This CVE is due to
- some people run their x servers as root
- and they allow arbitrary access to it over the internet
- and that x server contains a memory bug.

Solutions:
- don't run your x server as root
- don't allow random folks ssh your computer
- write an x server in rust or in other memory safe languages (GC-ed languages for example) (it will obviously contain many-many more bugs at first, and still for a long period while it reaches feature parity but after that more secure I guess).

Not a solution:
- replace your graphic protocol (???) to an other graphic protocol that is so secure that you can't screenshot your own screen

[Sevard]

I think you mean former Xorg server developers, as the ones who wanted a fresh start switched to working on wayland code.

Mostly same people. There is really no war between X and Wayland. And most people that work with Wayland specific code used to work or still work with X specific code. In fact some code is shared or implemented by the same person in both projects.
It's just time to move forward.

The Xorg server works for what it was intended to do and that handles most use cases. That being said, you can find developers that will call software broken in just about any project,

I'd say that most clients learnt to live with it and some things that X Server used to handle were moved elsewhere.

Former Linux developers working on microkernels will likely say that Linux is broken too and in a way, they are not wrong. The complaints are actually fairly similar. One bad kernel module being able to attack everything else is much like one bad X11 client being able to attack everything else connected to the X11 server. However, broken is not a very descriptive word.

Most former and current X Server devs claim that it's broken. Not because codebase is bad – there was a lot of effort to fix it and it's well structured code now. The issue is in X11 specification itself. Maybe it made a lot of sense 39 years ago, but it doesn't really work well anymore. And there is no shame in that. Nearly 40 years ago nobody imagined things like multiple GPUs, multi-monitor setups with different refresh rates, smartphones, tablets, fast internet etc.

And here is another post about this:

https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server.html

So no, X Server isn't mature. It's just abandoned. For a good reason. Like I wrote – it's time to move on.

[mdedetrich]

These are called outliers in statistics. Anyway, mature code is in general better than immature code. If you want to replace mature code with something that has yet to mature, you are going to have pain until the replacement matures. That is how things work and it is true regardless of how much you want to hear otherwise.

Judging by how many CVEs have been cropping up in so called "mature C code", you can't really call it outliers

Without doing formal verification, security bugs in software is practically a certainty, no matter what the developers do.

Oh for gods sake, Rust's borrow checker is akin to formal verification. Type systems are mathematical proofs (they are equivalent) and there is a proof for Rust's borrow checker. That means for the types of errors that Rust's borrow checker is checking for, they are formally verified not to happen.

I don't know why you keep on repeating this, you don't seem to understand what you are talking about.

[jacob]

Have you read the article? This CVE is due to
- some people run their x servers as root
- and they allow arbitrary access to it over the internet
- and that x server contains a memory bug.

But isn't that kind of the point? Until relatively recently, running X servers as root was required and many systems installed some 10 years ago and only updated in-place ever since would still have it. It doesn't have to allow open access from the Internet, it's a local exploit and, well, the server DOES contain a memory bug.

- don't run your x server as root

Which, depending on a user's situation, may not be possible, or the user may simply not know.

- don't allow random folks ssh your computer

No random folks needed, a ssh access to localhost from an unconfined malicious process will do.

- write an x server in rust or in other memory safe languages (GC-ed languages for example) (it will obviously contain many-many more bugs at first, and still for a long period while it reaches feature parity but after that more secure I guess).

No-one is going to rewrite an X server in rust, the "RIIR" meme is an in-joke within the Rust community but in practice, although it seems that every other day or so we hear about a new company or project adopting Rust, it's almost always for new developments, not to rewrite existing software. I'm all for GC where it is suitable, by the way, but a GC by itself doesn't protect you against memory bugs, it only releases memory that is no longer needed.

Not a solution:
- replace your graphic protocol (???) to an other graphic protocol that is so secure that you can't screenshot your own screen

Of course you can do screenshots on Wayland desktops. But this is the right approach for low-level OS software and interfaces: secure by default, and then add carefully considered exemptions and trusted code paths.

[NobodyXu]

Not a solution:
- replace your graphic protocol (???) to an other graphic protocol that is so secure that you can't screenshot your own screen

I have been using swaywm as a daily driver until I switched on Macbook Air and screenshot on it works fine.

[gotar]

Wayland is arguably more mature than Xorg: developers were able to learn from the mistakes in Xorg

Being aware of Poe's law, I don't know what do you mean, but either way - LOL

In case you're serious: Wayland developers didn't learn a sh* from mistakes of Xorg - if any, they learn how to dodge responsibility and create "just a protocol", without actual reference and de facto standard implementation, ignoring many valid use cases by "do in via extension". Today, if you want to compare Xorg, you should take wayland+weston+kwin+gnome+wlroots+dozens of duplicated and incompatible implementations of various solutions to real problems and count bugs in all that software.

The Xorg main caveats (not: mistakes, different times, different hardware, different ecosystem, different expectations) were:
- inherent insecurity,
- additional round-trips.
The lesser issues were:
- bloated protocol (disabling some obsoleted features making incompatible X11.5 would be easy),
- ancient codebase.

If the Wayland developers were capable of building feature-complete desktop, then after all these years we wouldn't have this conversation.
Instead, they've implemented their own (or Gnome's) vision of the world (CSD, missing "redundant" features) enforcing massive code duplication.

[gotar]

You honestly have no idea what you're talking about and Xorg has been mismanaged for so many decades that it's beyond help such that the only solution is a new project.

Nobody really thinks that X11 is fixable. The difference is - many of us think that Wayland is unfixable as well.


Wayland did a fine job with graphics stack. However, the functional desktop needs more than that.
You can't rely on engineers to design a car - it would have brilliant performance, but no seat for passengers and trunk.

You need many people of different skills to push important solutions, some of which need compromises in other areas.

Wayland Security Module library: last commit Mar 30, 2016.

[ryao]

Judging by how many CVEs have been cropping up in so called "mature C code", you can't really call it outliers

Rust code can have CVEs too, especially since CVEs are not solely concerned with the classes of bugs that Rust is supposed to avoid. Make a big enough codebase in Rust that is really important and there will be no end to its CVEs.

The only way to avoid CVEs is to do formal verification, but that is too hard to do for large codebases.

Oh for gods sake, Rust's borrow checker is akin to formal verification. Type systems are mathematical proofs (they are equivalent) and there is a proof for Rust's borrow checker. That means for the types of errors that Rust's borrow checker is checking for, they are formally verified not to happen.

I don't know why you keep on repeating this, you don't seem to understand what you are talking about.

You have no clue what formal verification is if you think it is only concerned with memory errors and other things that can be caught by static analysis. You can have bugs that do not involve memory errors and those bugs can be security issues. Here is a prominent example:

https://gotofail.com

There are other ways of having bugs, such as high level logic issues that nothing Rust does will prevent, since those cannot be caught by static analysis. Formal verification, unlike a compiler, will catch such bugs. To elaborate on how much more intelligent formal verification is, let us say that you have a formally verified compiler (note that the only one that exists is for C) and you replace the source code with the source code for awk (to give an extreme example). The verifier will complain that it is not what it is supposed to be. If you replace valid source code with valid source code that does something completely different, the rust compiler will not tell you it is not what it is supposed to be. Formal verification catches all bugs in code, including high level logic bugs. Putting an entirely different codebase that does something completely different in place of the source code for your software would be an extreme example of a high level logic bug.

Rust is a great option for new code bases, but it is not guaranteed to be better if you try to replace mature C code with it. For example, there was an attempt to write a ZFS driver in Rust that ended in failure. Perhaps if the effort kept going for a decade, it would have succeeded, but ZFS is an amazing piece of software that was incredibly hard to create and it is incredibly hard to re-invent (the btrfs guys have been trying for years with their own disk format design and are not there yet). Doing a rewrite in Rust is a recipe for pain, just from a technical standpoint. Reliability bugs are likely to be rampant in a rewrite until it matures.

That said, since the conversation has degenerated to you saying that I do not know what I am “talking about”, let me end this. The reliability requirements for the filesystem code that I write are likely far higher than those for any of the code you write, so between the two of us, when we differ on how to write reliable software, you are the one who has no idea what he is saying. I already considered a rewrite in Rust and my conclusion was that it is a recipe for more problems for many years until it reaches maturity. It might have fewer problems after maturation than the C code has today, but the 5 to 7 year disruption that would involve would be better spent improving the existing C code and it is likely that the end result of continuing to improve the C code would be similar with much less disruption. It is not just me who says this. Everyone I know who is responsible for software reliability came to the same conclusion. Just about everyone responsible for the reliability of mature code bases is also saying that rewrites in Rust are not worthwhile. That is also why Linus Torvalds is not embarking on a journey to rewrite Linux in Rust, but is accepting it for new drivers.

You could make an argument that Rust code is semi-formally verified against certain classes of bugs, but the same can be done with C code through sound static analysis. You would have a better argument that sound static analysis is available for free with Rust and costs exorbitant amounts with C. A problem with both of those arguments is that the rust compiler does not provide sound static analysis for unsafe rust and as far as I know, no one provides it. That means that C code can be semi-formally verified against various classes of bugs through sound static analysis, but equivalent Rust code that needs unsafe Rust cannot. That makes C a better choice for writing reliable software when you have access to sound static analysis. When someone writes a tool to provide sound static analysis to unsafe Rust, it would probably be cost prohibitive like it currently is for C. A further argument against doing rewrites is that using a sound static analyzer to retroactively eliminate all memory safety issues in C code is much faster than doing a rewrite in Rust.

Note that as far as sound static analysis for C is concerned, Astree is supposed to be the best, but beyond its 30 day trial, it is likely cost prohibitive. NASA IKOS for C/C++ is free, although on paper, it is not as good as Astree. I have yet to evaluate either of them, although I have plans to try them. Interestingly, C and C++ code verified by these analyzers is used in industries where software failures will cause people to die (as in a plane falling out of the sky or a nuclear power plant melting down). Industries where failures are less critical use other languages to “avoid the issues of C and C++”. The end result is that their software is less reliable than it would have been had they adopted the tools used by the nuclear and aviation industries to write reliable C/C++ code.

Lastly, the phrase “those who do not know history are doomed to repeat it” applies here. People have been trying to make bug free software since the dawn of modern computing. Every decade, there is no end of people who think that the latest idea will solve all of the problems and every decade, they are wrong. While new ideas are good, it is important to understand their limitations. With time, you will understand Rust’s limitations. Around that time, you will probably encounter people saying to rewrite all of the rust code in yet another language when improving the rust code would be far less painful and get a similar result in the time it takes to bring a rewrite to maturity. Of course, you will be told you have no clue what you are saying when you tell people this.