It was pointed out to me recently in the GamingOnLinux Discord, that the sudo package recently had a security flaw, so time to check for updates.
The sudo package is what's responsible for giving certain users or user groups the ability to run some (or all) commands as root or another user. A pretty important package, and of course one that needs to be secure. Nothing is perfect though of course, and security issues being reported and then fixed is a good thing.
Going by the US NVD (National Vulnerability Database) entry for it, they classed it as a High level issue. As described:
In Sudo before 1.9.12p2, the sudoedit (aka -e) feature mishandles extra arguments passed in the user-provided environment variables (SUDO_EDITOR, VISUAL, and EDITOR), allowing a local attacker to append arbitrary entries to the list of files to process. This can lead to privilege escalation. Affected versions are 1.8.0 through 1.9.12.p1. The problem exists because a user-specified editor may contain a "--" argument that defeats a protection mechanism, e.g., an EDITOR='vim -- /path/to/extra/file' value.
Giving that it needs a local attack, it does limit what people can do with it but still a good reminder to ensure your systems are up to date eh?
So if you're on at least sudo 1.9.12p2 you're good to go. Although, some distributions like Ubuntu use slightly different versioning so if you're on Ubuntu you should have 1.9.11p3. Fedora seems up to date too, but checking on System76's Pop!_OS it's only reporting sudo 1.9.9 for example (Edit: but as pointed out in comments, it has the patch as it's based on an older Ubuntu).
You can read a little more on it here.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
11 comments
☆ Promoted Comments
The version number on Ubuntu really depends on what release you're on. https://ubuntu.com/security/CVE-2023-22809
Because the Ubuntu security team backport patches to older releases, the release number may look way older than the one released by upstream. This is normal.
This is probably why Pop shows 1.9.9 if it's based off Jammy, where 1.9.9-1ubuntu2.2 is the patched version, as you can see from the changelog. http://changelogs.ubuntu.com/changelogs/pool/main/s/sudo/sudo_1.9.9-1ubuntu2.2/changelog
Last edited by popey on 15 February 2023 at 10:53 am UTC
Because the Ubuntu security team backport patches to older releases, the release number may look way older than the one released by upstream. This is normal.
This is probably why Pop shows 1.9.9 if it's based off Jammy, where 1.9.9-1ubuntu2.2 is the patched version, as you can see from the changelog. http://changelogs.ubuntu.com/changelogs/pool/main/s/sudo/sudo_1.9.9-1ubuntu2.2/changelog
Last edited by popey on 15 February 2023 at 10:53 am UTC
6 Likes, Who?
Full Comments
The version number on Ubuntu really depends on what release you're on. https://ubuntu.com/security/CVE-2023-22809
Because the Ubuntu security team backport patches to older releases, the release number may look way older than the one released by upstream. This is normal.
This is probably why Pop shows 1.9.9 if it's based off Jammy, where 1.9.9-1ubuntu2.2 is the patched version, as you can see from the changelog. http://changelogs.ubuntu.com/changelogs/pool/main/s/sudo/sudo_1.9.9-1ubuntu2.2/changelog
Last edited by popey on 15 February 2023 at 10:53 am UTC
Because the Ubuntu security team backport patches to older releases, the release number may look way older than the one released by upstream. This is normal.
This is probably why Pop shows 1.9.9 if it's based off Jammy, where 1.9.9-1ubuntu2.2 is the patched version, as you can see from the changelog. http://changelogs.ubuntu.com/changelogs/pool/main/s/sudo/sudo_1.9.9-1ubuntu2.2/changelog
Last edited by popey on 15 February 2023 at 10:53 am UTC
6 Likes, Who?
Thanks for the reminder on it, good tip. Nice to see older releases are up to date too :)
0 Likes
I do not understood. Could not sudo copy sudoers to allow editing it, setting special sudo users privileges, run editor on this privileges and replace edited file onto /etc/sudoers?
0 Likes
I do not understood. Could not sudo copy sudoers to allow editing it, setting special sudo users privileges, run editor on this privileges and replace edited file onto /etc/sudoers?
That’s what’s bad about this one. Sudo already has a process like what you described, but the command is supposed to check whether you should be allowed to.
This bug allows a malicious user to escape the check and get sudo to help them modify arbitrary files regardless of permission.
1 Likes, Who?
Again?! 
That was fast after the last one way back in January! (this year) I can rule out my laptop at least as that's currently in progress of upgrading to Fedora 38 
So let's say you've got a local exploit in Application A, for sake of argument I'll say Application A is sudo in this case. Now we know that application cannot be attacked remotely right?
Well not necessarily. If you also have a non-sandboxed Application B, say a web browser that happens to also have a vulnerability. If an attacker is able to get access to your local account via Application B, the web browser in this case, they can now proceed to perform a local attack on sudo, gaining root on your system.
Another method may be a pirated game, or a game from Itch.io which happens to contain some nasty code which may also try to attack your sudo.
Remember, a proper attack on a system is taking different vulnerabilities and putting them together to get as much access as possible. So local attack or not, it should still be treated with concern and patched as soon as possible.
That was fast after the last one way back in January! (this year) I can rule out my laptop at least as that's currently in progress of upgrading to Fedora 38 Giving that it needs a local attack, it does limit what people can do with itThis is the wrong way to look at local attacks. Hear me out.
So let's say you've got a local exploit in Application A, for sake of argument I'll say Application A is sudo in this case. Now we know that application cannot be attacked remotely right?
Well not necessarily. If you also have a non-sandboxed Application B, say a web browser that happens to also have a vulnerability. If an attacker is able to get access to your local account via Application B, the web browser in this case, they can now proceed to perform a local attack on sudo, gaining root on your system.
Another method may be a pirated game, or a game from Itch.io which happens to contain some nasty code which may also try to attack your sudo.
Remember, a proper attack on a system is taking different vulnerabilities and putting them together to get as much access as possible. So local attack or not, it should still be treated with concern and patched as soon as possible.
3 Likes, Who?
This is the wrong way to look at local attacks. Hear me out.
No, that's exactly the right way to look at a local attack - as Liam notes in the article, you should still patch it, but a local attack absolutely is limited in how it can affect your system. A second attack is needed to chain to this one.
The messaging couldn't be clearer in the article.
Of course, not really saying you're wrong... just that you're repeating the same message.
1 Likes, Who?
You can check your version with
Reminder: don't forget to update any hosts or systems you don't often get into.
sudo -VReminder: don't forget to update any hosts or systems you don't often get into.
4 Likes, Who?
For Ubuntu fixed packages for this was released on 2023-01-16, more info: https://ubuntu.com/security/CVE-2023-22809
Red Hat released patched versions on 2023-01-23, https://access.redhat.com/security/cve/CVE-2023-22809
Debian released patched versions on 2023-01-23, https://security-tracker.debian.org/tracker/CVE-2023-22809
I could not find any info for Arch on https://security.archlinux.org/ but it looks from their package database that they released patched versions around 2023-02-10, 2023-02-15
Most others probably follow the releases above as they usually are based on Debian or Ubuntu.
Red Hat released patched versions on 2023-01-23, https://access.redhat.com/security/cve/CVE-2023-22809
Debian released patched versions on 2023-01-23, https://security-tracker.debian.org/tracker/CVE-2023-22809
I could not find any info for Arch on https://security.archlinux.org/ but it looks from their package database that they released patched versions around 2023-02-10, 2023-02-15
Most others probably follow the releases above as they usually are based on Debian or Ubuntu.
0 Likes
Note: Before I write this post, I should mention I'm about half a bottle of rum down.. so don't expect it to be entirely coherent!This is the wrong way to look at local attacks. Hear me out.
No, that's exactly the right way to look at a local attack - as Liam notes in the article, you should still patch it, but a local attack absolutely is limited in how it can affect your system. A second attack is needed to chain to this one.
The messaging couldn't be clearer in the article.
Of course, not really saying you're wrong... just that you're repeating the same message.
To be clear, I'm not in disagreement here.
While the view of "you need to chain it" is true. You have to consider that in relation to GOL users, that's not such a hard task since most readers are probably using Linux as a desktop (as in user, not laptop vs desktop etc). This means chained attacks are the most likely in any situation.
The security implications are much more significant when you consider it from a user perspective. As a server? Sure it's in most cases not a big deal and would be difficult to exploit.
As a desktop user? well it could be exploited easily.
We should not forget that most users are using the software from a "I download this game, I think it's safe" perspective. What that means is, they are trusting the game to run legit code that doesn't try to exploit another binary. But the fact remains we can't be sure of this, particularly with proprietary software.
I used itch.io as an example previously, not because it's a bad store, but rather from my understanding it generally promotes developers uploading their own binaries without checking the binaries the user downloads for potential issues. This in itself is a potential threat to the user if said developer is not the most ethical of people.
As a desktop user, every day we perform actions we hope won't attack our system, whether it's downloading a game, a music file or just browsing a website. All of these, could lead to an attack on a vulnerable sudo if it is not updated.
Thus I feel my point stands, local only attack or not - it should be patched ASAP.
(Thankfully we're heading to more sandboxing, which makes most of these points moot, thankfully!)
1 Likes, Who?
Debian released patched versions on 2023-01-23, https://security-tracker.debian.org/tracker/CVE-2023-22809Well, Debian announced the availability of updated packages on January 18: https://www.debian.org/security/2023/dsa-5321 and if I am interpreting this correctly, then Arch released 1.9.12p2 also on January 18: https://github.com/archlinux/svntogit-packages/commits/packages/sudo/trunk
I could not find any info for Arch on https://security.archlinux.org/ but it looks from their package database that they released patched versions around 2023-02-10, 2023-02-15
For everyone interested in keeping track of security related package updates there is (at least for Debian) a mailing list you can subscribe to: https://lists.debian.org/debian-security-announce/
Last edited by axelb on 17 February 2023 at 10:51 pm UTC
1 Likes, Who?
Patreon
PayPal
See more from me