X.Org Server Hit By Its Latest Batch Of Security Vulnerabilities

[phoronix]

Phoronix: X.Org Server Hit By Its Latest Batch Of Security Vulnerabilities

Given the age of the X.Org/X11 code-base security issues have become quite frequent. It was nearly a decade ago that the X.Org Server was considered a "security disaster" and a security researcher saying it's even worse than it looks. Today another batch of X.Org Server security vulnerabilities have been made public...

https://www.phoronix.com/scan.php?page=news_item&px=X.Org-Server-December-2021

[mppix]

... This is going to be fun.

[SkyWarrior]

Are we surprised?








No

[andyprough]

Alternate headline - "XWayland Hit By Its Latest Batch Of Security Vulnerabilities"

All just a matter of viewpoint I guess. Should we even have an XWayland? Just continues to expose users to vulnerabilities while transitioning to Wayland, it would seem in some cases.

I'd be interested to know if these vulnerabilities are a problem for openBSD's xenocara or not. Seems like they may have gone in the correct direction 14 years ago.

[jntesteves]

Four more CVEs were made public today around input validation failures in the X.Org Server that could lead to local privilege escalation. This is for cases where the X.Org Server is still running as a privileged process and supporting remote code execution for SSH X forwarding sessions.

These security advisories do impact XWayland

I'd guess these are low severity on XWayland (and non-root Xorg) since the whole privilege escalation part isn't possible anyway. Still, it's important to fix any out-of-bounds accesses.

Edit: Also, no RCE on XWayland.

[Charlie68]

Alternate headline - "XWayland Hit By Its Latest Batch Of Security Vulnerabilities"

All just a matter of viewpoint I guess. Should we even have an XWayland? Just continues to expose users to vulnerabilities while transitioning to Wayland, it would seem in some cases.

I'd be interested to know if these vulnerabilities are a problem for openBSD's xenocara or not. Seems like they may have gone in the correct direction 14 years ago.

The vulnerability is in Xorg so the title is correct, obviously Xwayland is also affected which seems to have already had a fix.
The reason why Xwayland is part of the wayland session is only to allow backward compatibility with applications that do not yet support wayland natively, it is the developers of these applications who should strive to support new technologies.
However all GTK3 + and Qt5 + applications natively support wayland, Firefox has native wayland support and chrome / mium is on its way, just set a flag.
But in the application universe there are still applications that need Xwayland, but not many.

[cl333r]

Sorry for the off-topic, but also security related.
I have a file browser I'm creating that I want to allow the user to manage root protected files (e.g. system files) by
1) querying him for the root password, then
2) executing sudo -S (password) (daemon_exe) (not using pkexec because it doesn't work with GUI/X11 apps).
3) daemon_exe is a lightweight daemon that when it starts it listens on a socket(AF_UNIX, SOCK_STREAM, 0), executes the first command it gets and exits.

I imagine the problem with this is that in theory it's possible that in between launching this privileged daemon and sending it an I/O command some other app might maliciously intervene and tell it to do nasty things as a root. If that's the biggest problem - how should it be tackled? Or to be more precise, how do I make sure that the newly started daemon will only execute the command it receives thru a socket from my app, not some other one?

[d3coder]

So, Xorg got another security research. Did any desktop wayland compositor got at least one security research?

[ssokolow]

Sorry for the off-topic, but also security related.
I have a file browser I'm creating that I want to allow the user to manage root protected files (e.g. system files) by
1) querying him for the root password, then
2) executing sudo -S (password) (daemon_exe) (not using pkexec because it doesn't work with GUI/X11 apps).
3) daemon_exe is a lightweight daemon that when it starts it listens on a socket(AF_UNIX, SOCK_STREAM, 0), executes the first command it gets and exits.

I imagine the problem with this is that in theory it's possible that in between launching this privileged daemon and sending it an I/O command some other app might maliciously intervene and tell it to do nasty things as a root. If that's the biggest problem - how should it be tackled? Or to be more precise, how do I make sure that the newly started daemon will only execute the command it receives thru a socket from my app, not some other one?

Why do you need daemon_exe at all? Just feed the command to sudo directly.

[cl333r]

Why do you need daemon_exe at all? Just feed the command to sudo directly.

You mean feeding it commands like "rm" directly? Off the top of my head - mainly because I'm not versed in command utilities and because it would need to do things like moving to a trash can or some other logic that I don't know how to do with utilities + other reasons like if the user selects say 500 files to delete I'd have to pass the utility 500 file paths on the command line, I'm not sure such things work OOTB. So, because I want more flexibility and I'm not versed in admin tools.