X.Org Server 1.19.5 Released To Fix Another Handful Of Security Vulnerabilities

[bison]

C is a terrible language, please stop writing code in it.

That's certainly a disproportionate response. Better advice might be to allocate strings on the heap using strdup and asprintf, and use ASan and/or valgrind to check for errors.

[oiaohm]

Baby + Bath water. Reality everything take a breath and go look at sel4. Sel4 program language is C but it does not have the major issues. Why it C with computer executable specification. The specification of sel4 is in Haskell.

One of the issues with C++ is performance.

sel4 C code breaks rules.
The formalisation includes low-level and unsafe C programming constructs like pointer arithmetic and pointer cast.
So yes sel4 C code includes all the things that we call unsafe but the specification verification means none of that usage is invalid so no buffer overflows or other issues like it.

Going to C++ or rust or any other language really does not get away from executable specification if you want absolutely validated. What is special about executable specification is it based on mathematical proof methods. So a mathematical proof can take all possible values into consideration in a single pass. Test casing or fuzzing or user testing is only testing a limited set of values.

Reality is most of the issue is not the program language but the method we have used to quality control what has been coded.

[Guest]

Baby + Bath water. Reality everything take a breath and go look at sel4. Sel4 program language is C but it does not have the major issues. Why it C with computer executable specification. The specification of sel4 is in Haskell.

One of the issues with C++ is performance.

sel4 C code breaks rules.
The formalisation includes low-level and unsafe C programming constructs like pointer arithmetic and pointer cast.
So yes sel4 C code includes all the things that we call unsafe but the specification verification means none of that usage is invalid so no buffer overflows or other issues like it.

Going to C++ or rust or any other language really does not get away from executable specification if you want absolutely validated. What is special about executable specification is it based on mathematical proof methods. So a mathematical proof can take all possible values into consideration in a single pass. Test casing or fuzzing or user testing is only testing a limited set of values.

Reality is most of the issue is not the program language but the method we have used to quality control what has been coded.

I guess you're talking about https://github.com/seL4/seL4 / https://sel4.systems/ , but this is not a language, but it's a microkernel.

[oiaohm]

This is not hard coded the core design of the protocol to lock out security features. It is completely feasible to design an extension to implement security policy profiles to address this. What could have fixed this would be a security extension to control which applications if any should be privileged to access which windows. Normal applications can then be constrained to their own window and its children. Some of this was addressed by Xsecurity extension.

There are issues coded into the X11 design core. Major difference between X11 and wayland.
X11 uses strings in a lot of places that cause security issues.

http://xwindow.angelfire.com/page28.html

Like here char *display_name;
Under wayland this will be a file handle.

The hard code bit in the X11 design that locks out proper security being done as anything more than a hack is using strings over and over again for stuff that should be done by a file handle. Also file handle is a fixed size and strings are dynamic. Wayland protocol contains less dynamic size allocations than X11 displaying the same stuff. Less dynamic size allocations less places to stuff up and have a buffer overflow . When the data is dynamically sized in Wayland is wrapped under a file handle so able to use file access protection against reading past the end of the file so prevents buffer overflow..

Security profiles auditing everywhere X11 uses strings so they are correct gets really heavy really quick.

Wayland exploits OS feature each application has it own file handle table and you have to use file handle pass commands to send a file handle from 1 application to another under modern OS like Linux and BSD. So this automatically means application cannot access what it has not be authorised to by some means.

Also the dispute over multi Wayland compositors over looks that X11 Windows managers and compositing solutions have access to basically everything and those crashing could leave end user stuffed anyhow. So massive parallel code doing the same thing is X11 anyhow.

[oiaohm]

I guess you're talking about https://github.com/seL4/seL4 / https://sel4.systems/ , but this is not a language, but it's a microkernel.

sel4 is example of something coded in C that is in fact high quality. Read my text again I did not say Sel4 is a language.

https://github.com/seL4/l4v

There are multi different languages used in different parts of it proofing system. The final micro-kernel of Sel4 is C. So C with enough quality control is not a problem and there are performance advantages to some of C risky code particularly if you can know it safe. Choosing another language other than C you may reduce issues but without running a formal proof of some form quality will still be missing. So formal proof need to come part of normal development somehow.

Now something like X11 server lot of C, no proofing system, lots of dynamic size allocations this reads big trouble. Yes the more dynamic allocations to read the more odds of buffer overflow coding or buffer under read errors. Now lot of languages like rust will protect you from overflow but that don't check if you program takes the wrong logic response because it under read. This is the problem coding languages can only remove so many problems. Formal proof has exact information what program should be doing so can find things the program complier no matter the language will without question miss.

[Guest]

sel4 is example of something coded in C that is in fact high quality. Read my text again I did not say Sel4 is a language....

Yes, I see. But, you really should learn English better. You might have great ideas, but without the ability to explain them precisely, these ideas would easily be missed(or misinterpreted) by others. At least start using comma,...

As with programming, it doesn't matter much on language, but on the programmers ability to use the language properly.

[rewik]

I'd hate to break it to people here but Wayland has potential security problems that eclipse X due to the reliance on direct rendering in applications, and the lack of indirect (network transparent) stream based protocol like X has with with core protocol and GLX. Direct rendering maps video RAM and video hardware interfaces into the applications. This is basically asking for trouble should there be a security problem in the video hardware.

So your giving a much larger body of more questionable application code direct contact with video hardware, whereas the X server traditionally only touched video hardware. With X being a userspace process, it would have been possible to constrain X with a security profile using something like apparmor, with fine grained security controls that give it access just to the hardware resources it needs.

All large C programs have security problems. The problem is C, not X, and speed-fanatics who think that everything needs to be written in dangerous C code for that little bit extra speed. Wayland also is written in C, do not assume it does not have the same problems. Wayland and X.org were written by the same people.

Also, Wayland does reinvent the wheel. There is no point in it. Performance profiling has shown virtually no speed improvement of Wayland over X. Everything Wayland was sold on can be done with double buffering and verticial synchronization extensions to X and by the already underway work to port X.org to an OpenGL/DRI/EGL backend itself. This would fix visual artifacts.

As for legacy features in X, the sensible thing for that would be to have a runtime flag to disable those features and break out legacy support code into runtime loaded libraries for this purpose. Thus if you dont use an app that needs the legacy feature, you dont have to load the code that it uses. These legacy features are not great in number, usually some 2D graphics primatives and some older font APIs.

Its important to note that the problem with the older graphics primatives was they were not powerful enough, most apps now need a rich set of 3D graphics operation. The traditional X protocol provides far, far too few primatives, OpenGL apps need a much richer set of primatives. Wayland apps do use a vast number of OpenGL primatives, which have to make it to the video adapter, it doesnt provide the option of isolating apps from the video hardware however, due to the lack of an indirect protocol.

The rest of the X.org code base can be fuzz tested and scanned with security tools to spot possible problems.

So, one by one, all of the arguments for Wayland can be debunked.

That's such a combination of truths, half-truths and misconceptions that it's hard to get my head around.
Please watch those two videos:
https://www.youtube.com/watch?v=GWQh_DmDLKQ (from Linux.conf.au 2013)
https://www.youtube.com/watch?v=Zsz7Shbnb9c (from FOSSASIA 2017)

[michael-vb]

There are issues coded into the X11 design core. Major difference between X11 and wayland.
X11 uses strings in a lot of places that cause security issues.

http://xwindow.angelfire.com/page28.html

Like here char *display_name;
Under wayland this will be a file handle.

I may be wrong here, as I do not have the details of the protocol in mind and am too lazy/busy to look them up now, but isn't that an issue in Xlib rather than X11?

I do think that some of the remaining problems in X11 could still be solved. Legacy protocol request handling could really be re-written in a slow but safe way, perhaps really using a safe language which produces object code which can be linked into C; but there are many ways of doing this, and I even seem to recall KeithP rewritting them as GL shader code. I think that the old issue of keyboard grabs interfering the screen saver has already been solved by lower levels of the operating system just using a separate X server on a different VT for the screen saver. I presume that the X.Org screen saver interface simply notifies these lower layers nowadays rather than trying to start a screen saver on the active server. And the problem with different clients spying on each other could be solved by splitting up the X server into several logical servers (this could be done inside the X server process, or by without changing X server code at all by interposing proxy X servers, or possibly using the X security extension), which only provide limited information about clients on other logical servers, say window position but not window contents.

Of course, since the X server developers have decided to go with Wayland, this is only relevant to people who still have to support configurations which can't move away from X. One may agree or disagree with the X developers, but the saying about paying the piper applies.