X.Org Server Hit By New Local Privilege Escalation, Remote Code Execution Vulnerabilities (phoronix.com) 24
Getting things started for this "Patch Tuesday" are the disclosure of two new X.Org Server vulnerabilities. Phoronix reports: These issues affecting out-of-bounds accesses with the X.Org Server can lead to local privilege elevation on systems where the X.Org Server is running privileged and remote code execution for SSH X forwarding sessions.
CVE-2022-2319 and CVE-2022-2320 were made public this morning and both deal with the X.Org Server's Xkb keyboard extension not properly validating input that could lead to out-of-bounds memory writes. Fixes for these XKB vulnerabilities have been patched in X.Org Server Git and xorg-server 21.1.4 point release is expected soon with these fixes. Both vulnerabilities were discovered by Trend Micro's Zero Day Initiative.
CVE-2022-2319 and CVE-2022-2320 were made public this morning and both deal with the X.Org Server's Xkb keyboard extension not properly validating input that could lead to out-of-bounds memory writes. Fixes for these XKB vulnerabilities have been patched in X.Org Server Git and xorg-server 21.1.4 point release is expected soon with these fixes. Both vulnerabilities were discovered by Trend Micro's Zero Day Initiative.
xhost + (Score:1)
Oh boy, X server vulnerabilities .. such fun memories.
Only if you're running X as root (Score:1)
Do any of the "standard" Linux distributions still run X as root?
Re:Only if you're running X as root (Score:5, Informative)
* this is really provided by GDM3, which will run Xorg root-less, if KMS is available. Also, distributions that use LightDM will be running a root Xorg, but they're not common.
If KMS is unavailable, it will run Xorg as root.
There are many situations where your hardware may fall into that situation "by default" (using an NVIDIA card without an iGPU is the big one), but you can enable KMS on all common configurations I'm aware of- including the NVIDIA scenario.
Re: (Score:2)
What about SDDM?
Re: (Score:2)
I don't regularly use any KDE distributions, so I'm not sure what the status of that is.
Asahi on my Air is running Arch+SDDM+KDE, so I'll check it out real quick... and it's root.
Re: (Score:1)
Re: (Score:3)
Its default is to load Wayland if it's available, Xorg otherwise, as the logged in user if KMS is available, root otherwise.
Re: (Score:1)
Patch Tuesday? (Score:3)
Re: (Score:2)
doesn't matter, the author got a moment of smug face when they wrote it thinking they were in in some 1337 joke. Probably by the same type of person that will tell you "I have been writing on this topic for 25 years" (smug hahaha) but yea how many year have you actually done the thing your writing about ... oh none thanks for the input
Re: (Score:2)
Given how ubiquitous Windows is, my understanding is that a number of organizations (like Oracle and Adobe) also began adopting Microsoft's "Patch Tuesday" cadence.
I don't know to what extent any open-source providers follow this trend. It would be a weird coincidence if they just happened to publish information about this vulnerability on Patch Tuesday, though, so maybe other orgs *do* try to synchronize when possible.
Re: (Score:3)
The odds against it being a co-incidence are astronomical!. Tuesdays are extremely rare, they only occur in one out of every FIVE weekdays!!1! And the rate goes down to one in seven if weekends are included.
OTOH, there's a good chance that there will be at least one in every week, depending on location and what the official language is.
Re: (Score:2)
Very droll, but Patch Tuesday is the second Tuesday of the month, not every Tuesday. Still not astronomical, but a bit more coincidental.
Re: (Score:1)
Re: (Score:2)
> Why is this called Patch Tuesday? Isn't that a Windows (not a X Window) thing?
Judge the author accordingly.
remote code execution seems a stretch (Score:2)
Re:remote code execution seems a stretch (Score:4, Informative)
Seems like calling this a remote code execution bug is kindof a stretch.
Absolutely not.
Using X forwarding over ssh is known to only be as secure as the server one is logging into.
This is true.
Calling this a remote execution bug is a pretty short step away from saying that all local privilege escalation bugs are remote execution bugs because a file transfer application could be used to download a malware executable from an unsecured remote server.
This is a terminally broken analogy.
In one, a user account with an expected set of privileges, which may or may not be communicating X remotely, can achieve escalated permissions.
Since X and SSH facilitates communication remotely of the local protocol, the exploit is in fact remote capable.
In your situation, it requires affirmative action from a local agent on the machine to execute the malware.
A better example, using your framework, would be if you could upload something via a fileserver, and get the system to automatically execute it as root.
Which would be an RCE, just like this is.
OK, where we at with X.org vs. XFree86 these days? (Score:2)
OK, where we at with X.org vs. XFree86 these days?
Asking for a friend.
Re: (Score:2)
XFree86 has been stone dead for almost two decades.
Re: (Score:2)
Re: (Score:2)
XFree86 last updated in 2014. I think there are 4 (or less) people in the world who actually understand X-Windows. There are many people who will complain about Wayland, but zero of those complainers will actually help with XFree86.
The joy of C (Score:2)
Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interest of efficiency on production runs. Unanimously, they urged us not to—they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law.