sudo-rs Affected By Multiple Security Vulnerabilities

[–] ISO@lemmy.zip 42 points 3 days ago* (last edited 3 days ago) (3 children)

Nice(!) to see so many people who don't know anything about programming get successfully propagandized into going against something they know nothing about.

Below is a list of CVE's published against original sudo, all within the last 5 years. You may not heard of them, because CVE's against non-Rust projects are not news 🫣

`sudo` CVE's from within the last 5 years

(severity scores are not available/assigned always)

CVE-2021-3156 (Severity: High)

Sudo before 1.9.5p2 contains an off-by-one error that can result in a heap-based buffer overflow, which allows privilege escalation to root via "sudoedit -s" and a command-line argument that ends with a single backslash character.

CVE-2021-23239

The sudoedit personality of Sudo before 1.9.5 may allow a local unprivileged user to perform arbitrary directory-existence tests by winning a sudo_edit.c race condition in replacing a user-controlled directory by a symlink to an arbitrary path.

CVE-2021-23240

selinux_edit_copy_tfiles in sudoedit in Sudo before 1.9.5 allows a local unprivileged user to gain file ownership and escalate privileges by replacing a temporary file with a symlink to an arbitrary file target. This affects SELinux RBAC support in permissive mode. Machines without SELinux are not vulnerable.

CVE-2022-43995 (Severity: High)

Sudo 1.8.0 through 1.9.12, with the crypt() password backend, contains a plugins/sudoers/auth/passwd.c array-out-of-bounds error that can result in a heap-based buffer over-read.

CVE-2023-7090 (Severity: Medium)

A flaw was found in sudo in the handling of ipa_hostname, where ipa_hostname from /etc/sssd/sssd.conf was not propagated in sudo. Therefore, it leads to privilege mismanagement vulnerability in applications, where client hosts retain privileges even after retracting them.

CVE-2023-22809 (Severity: High)

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.

CVE-2023-27320 (Severity: High)

Sudo before 1.9.13p2 has a double free in the per-command chroot feature.

CVE-2023-28486

Sudo before 1.9.13 does not escape control characters in log messages.

CVE-2023-28487

Sudo before 1.9.13 does not escape control characters in sudoreplay output.

CVE-2023-42465

Sudo before 1.9.15 might allow row hammer attacks (for authentication bypass or privilege escalation) because application logic sometimes is based on not equaling an error value (instead of equaling a success value), and because the values do not resist flips of a single bit.

CVE-2025-32462 (Severity: Low)

Sudo before 1.9.17p1, when used with a sudoers file that specifies a host that is neither the current host nor ALL, allows listed users to execute commands on unintended machines.

CVE-2025-32463 (Severity: Critical)

Sudo before 1.9.17p1 allows local users to obtain root access because /etc/nsswitch.conf from a user-controlled directory is used with the --chroot option.

The special comment from @MTK@lemmy.world in this thread deserves some focus:

The Rust hype is funny because it is completely based on the fact that a leading cause of security vulnerabilities for all of these mature and secure projects is memory bugs, which is very true, but it completely fails to see that this is the leading cause because these are really mature projects that have highly skilled developers fixing so much shit.

So you get these new Rust projects that are sometimes made by people that don’t have the same experience as these C/C++ devs, and they are so confident in the memory safety that they forget about the much simpler security issues.

This has all the classics from the collectively manic discourse that has been spreading lately

mature projects

highly skilled developers

Rust projects that are sometimes made by people that don’t have the same experience as these C/C++ devs

C/C++ devs (deserves a separate entry)

they forget about the much simpler security issues.

The only classic missing is "battle tested" which is a crowd favorite these days.

But of course the internet gantry's knowledge about CVE's reported against non-Rust projects, is as good as their understanding of the Rust language itself.

Someone bothering to be minimally informed, even when lacking the technical knowledge to maximize their understanding of the information, would have known that the original "mature" sudo has CVE's published against it all the time. A CRITICAL one was rather recent even. And as it just happens, the ones not (directly) related to memory safety did outnumber the ones that did recently (5 year span). Which ones had higher severity is left as homework for the internet gantry.

The discourse centered around memory safety is itself lacks the knowledge to realize that the overall value proposition of Rust is much bigger than this single aspect, although the breadth of sub-aspects that cover memory safety offered by Rust is itself also under-grasped.

The internet gantry's susceptibility to propaganda and good old FUD done by ignorant and drama mongering "influencers" and "e-celebs" would have been almost concerning, that is if their transient feelings mattered in any way, in the grand scheme of things.

Needless to say, but this is comment is not meant to be disparaging towards Todd C. Miller or any other sudo developer/maintainer. He has a good relationship with sudo-rs developers anyway, not that the internet gantry would know.

[–] Shanmugha@lemmy.world 10 points 3 days ago (1 children)

Nah, it's just that a whole lot of people, me included, are tired of foolish "but Rust is safe!!!1" propaganda-like shallow screams, like kids getting a new toy. I am ok when watching Linux distro battles, because that's by definition child's play and individual experience varies wildly among participants, but regarding programming languages I would rather see a long boring description of what is tackled how and why this is better than the "bad and buggy" alternative than this cheap shouting.

P.S. the critics does not go to you personally, yours is a good post, I thank you for it

[–] arcterus@piefed.blahaj.zone 7 points 3 days ago (1 children)

Nah, it's just that a whole lot of people, me included, are tired of foolish "but Rust is safe!!!1" propaganda-like shallow screams, like kids getting a new toy.

Okay, and I'm tired of seeing every Rust-related thread filled with random idiots shitting on Rust for no real reason (often unprompted, with no actual argument other than "hurr durr stupid cult of rust bad hurr durr why use rust when c do trick") and then go on about how the brilliant, genius, enlightened C programmers will save us with their 3000 IQ brainpower and never make mistakes. It's just tiring. Every Linux discussion about Rust, every discussion about some software being rewritten in Rust (even by the original developers), every discussion even tangentially related to Rust ends up like this.

load more comments (1 replies)

[–] EnEnCode@programming.dev 6 points 3 days ago

Better than I could have ever put it. But to add my own thoughts, sudo-rs does not gain value just by being in Rust.

It's a more lean sudo with compatability for common flags while intentionally not implementing niche/legacy options, including the one used by CVE-2025-32463, though if I did not need any of those flags at all, I would (and in past, have) just use opendoas.
The project contains extensive testing and a harness versatile enough to also test the OG sudo and has caught regressions in it. The rewrite wanting parity with sudo's behavior has improved the original sudo; you can gain its benefits even if you won't/don't/can't run it. This is the main reason uutils hasn't convinced me of its worth yet.
Having more eyes on sudo is just good. By translating it, they have to understand many of sudo's poorly-documented idiosyncracies and review all its relevant code and consider potential potential edge-cases. That's basically an audit.

[–] sem@lemmy.blahaj.zone 4 points 3 days ago (2 children)

The discourse centered around memory safety is itself lacks the knowledge to realize that the overall value proposition of Rust is much bigger than this single aspect, although the breadth of sub-aspects that cover memory safety offered by Rust is itself also under-grasped.

What is the value proposition of Rust? I thought it was entirely about memory safety. But I'm not a programmer.

[–] ISO@lemmy.zip 13 points 3 days ago (1 children)

Rust has features that are not directly related to memory safety, but introduce paradigmatic and ergonomic improvements that help writing correct logic more often. Features like sum types (powerful enums) and type classes (traits, how generics are implemented) quickly come to mind. Hygienic macros and procedural macros are also very powerful features.

Sometimes the two aspects (language feature and memory safety) come together. For example, the Send and Sync traits is the part of the type system that contributes to implementing thread safety.

So it's not all just about (im)mutability, lifetimes, and the borrow checker, the directly relevant safety features.

Also, the tooling and the ecosystem are factors the value of which can not be understated.

[–] banshee@lemmy.world 7 points 3 days ago

Well said. I personally enjoy using a systems-level language with a handful of functional programming features. I also enjoy the support for async runtimes and other concurrency features (channels).

Rust allows me to get away from more boring (to me) languages (e.g. JS/TS, Java, Kotlin).

load more comments (1 replies)

[–] nyan@lemmy.cafe 15 points 3 days ago (1 children)

All non-trivial software has bugs, and it's unsurprising that in a sudo implementation in any language, many of those bugs are security-related. This is still quite young software. Ubuntu was premature in making it their default, I think, but that just means it's immature, not that it's completely broken.

Then again, I use su exclusively and don't even have sudo installed, so I've got no dog in this fight.

(As for Rust itself, I am neither for nor against. It's a programming language. It has some issues that mostly seem to be related to how building and distribution is carried out in practice, rather than the core language design. I have never met a programming language without warts, and I've used several. If you're experienced with the language—whatever it is—you learn how to handle them.)

[–] guynamedzero@piefed.zeromedia.vip 1 points 3 days ago* (last edited 3 days ago) (1 children)

If you don’t mind me asking, what are the benefits of su over sudo? I’ve heard that some people (like you) only use su instead sudo, but I haven’t really seen the reasons for why

[–] nyan@lemmy.cafe 3 points 2 days ago* (last edited 2 days ago)

In my case, part of it is that sudo is an extra installation for me on Gentoo, while su is part of the base system on any Linux. Given that all nontrivial software has bugs, every unneeded package you install adds very slightly to your security risk.

In terms of security, sudo is better in the environment for which it is intended: a system with multiple human users that has a dedicated sysadmin who curates /etc/sudoers and makes sure that no user has more permissions than they absolutely need. However, only a small fraction of all machines running Linux meet those criteria. On the typical home system that's using some distro's default sudo-with-user-passwords setup, you can get root authority with only one password, whereas with su you need the passwords for both a wheel account and the root account. That isn't much added security, but every little bit helps. On the other hand, sudo can be set to require you to enter your password again after a period of time, while su will allow a root session to hang on unto infinity, which may matter if untrusted Linux-savvy people have physical access to your machine (I don't have that issue).

In other words, the benefits are real but minor and situational.

(None of this holds if you've done something really stupid in your configuration, like always starting an SSH server that allows both password login and direct root login when the system comes up. Always follow current best practice—in this case, certificate login only, and no direct root login—when setting up something that can be accessed over the network.)

(Some people claim that sudo has stopped them from unintentionally running a command as root. I just assume any console I'm using has root privileges and I shouldn't run dodgy commands in it to begin with.)

[–] just_another_person@lemmy.world 47 points 4 days ago (7 children)

Which batch of you turds was in here all up in my stuff last week when I said Rust projects have security vulnerabilities all the time just as any other and you all were arguing like "nuh-uh cuz Rust"?

Step up.

[–] entwine@programming.dev 51 points 4 days ago (1 children)

Everyone knows that memory safety isn't the only source of security vulnerabilities (unless you're bickering about programming languages on the internet, in which case 100% of security vulnerabilities are related to memory safety)

Rust users are one of Rust's biggest weaknesses.

[–] eah@programming.dev 3 points 3 days ago

memory safety isn’t the only source of security vulnerabilities

I would like you to produce an example of a Rust evangelist disputing this. They're not as dimwitted or misguided as you seem to think.

[–] arcterus@piefed.blahaj.zone 30 points 4 days ago* (last edited 4 days ago) (4 children)

Weren't you the dude posting completely irrelevant articles? As I said before, no one reasonable thinks Rust programs won't have bugs. Rust helps prevent a specific class of vulnerabilities. The rest is, as per usual, up to the programmer to avoid.

EDIT: I browsed your comments to verify. You were indeed the person posting the irrelevant articles about malware written in Rust being used to exploit other programs and using it to claim that software written in Rust was vulnerable.

load more comments (4 replies)

[–] MTK@lemmy.world 32 points 4 days ago (1 children)

The Rust hype is funny because it is completely based on the fact that a leading cause of security vulnerabilities for all of these mature and secure projects is memory bugs, which is very true, but it completely fails to see that this is the leading cause because these are really mature projects that have highly skilled developers fixing so much shit.

So you get these new Rust projects that are sometimes made by people that don't have the same experience as these C/C++ devs, and they are so confident in the memory safety that they forget about the much simpler security issues.

[–] mesamunefire@piefed.social 14 points 4 days ago (1 children)

Cant tell you how many times Ive heard about curl getting re-written. Same deal.

[–] otacon239@lemmy.world 11 points 4 days ago* (last edited 4 days ago) (1 children)

Surely a direct stream from the internet straight onto host hardware can’t be exploited in any way. All you gotta do is put the stream in a file. How hard could it be? (/s)

[–] arcterus@piefed.blahaj.zone 4 points 3 days ago (1 children)

Tbh that specific case probably wouldn't be a big deal. It's all the extra processing curl can do for http requests and the like that'd be more dangerous to rewrite I'd think.

[–] MoSal@programming.dev 2 points 3 days ago (1 children)

The most relevant part of the curl project is the library, not the CLI tool. And its biggest advantages in addition to universal availability is support for many protocols other than HTTP, flexible interface(s), two useful well-documented and largely stable APIs (one wraps the other for easy use), multiple TLS/SSL back-end support, and finally, the complete(ish) HTTP protocol support. But that last one alone is not that big of a deal. libcurl's implementation even uses external libraries for both HTTP2 and HTTP3 for framing. It uses an external library for QUIC transport support too. Meanwhile, many other independent language implementations for HTTP exist that range from serviceable to complete. Be it Python, Go, Rust, or many others, you usually get a "native" option you could/should use. Gone are the days of bad old PHP. Hell, even some WIP languages add usable native implementations sometimes as a part of their standard libraries, like inko.

Within the Rust ecosystem, you're fully covered by hyper. Even very obscure HTTP features like obsolete HTTP1 multi-line headers are supported (you have to enable this one explicitly). And I only know this because I had the fortunate circumstance of coming across a server that used these (It was an educational, if interesting, couple of afternoon hours).

load more comments (1 replies)

[–] zap12344@feddit.it 14 points 4 days ago (1 children)

To me this says more about Canonical than Rust.

[–] just_another_person@lemmy.world 9 points 4 days ago (2 children)

Canonical didn't make these tools...

[–] caseyweederman@lemmy.ca 21 points 4 days ago (1 children)

They do have a habit of overcommitting to tools that are not yet ready.

[–] 4am@lemmy.zip 15 points 4 days ago (1 children)

Hell, snap still isn’t ready

load more comments (1 replies)

[–] vga@sopuli.xyz 16 points 4 days ago* (last edited 4 days ago)

They did choose to adapt them at version <1.0.0

Could be a brave decision that will lead to these tools getting good a lot faster. Many such decisions seem a bit stupid if you only look at the short term.

[–] rikudou@lemmings.world 10 points 4 days ago

The biggest problem with Rust are its users. They somehow think that having a safe memory access means fewer bugs. While it only means fewer memory management related bugs. Which honestly isn't even a problem with modern C++.

load more comments (2 replies)

[–] DmMacniel@feddit.org 23 points 4 days ago

Hurray but at least those security vulnerabilities are memory safe!!!

[–] gravitas_deficiency@sh.itjust.works 30 points 4 days ago (2 children)

So:

yes, that’s pretty sketchy
this is also AFAIK the first major distro that it’s been a part of as a stock install, so this is the first exposure at scale that the project has had; as unfortunate as it is, it can be argued that this might fall under “teething issues”
with that said, it sounds like the rust coreutils people need to step up their game in terms of thinking in and testing for adversarial contexts. Normal test cases do not cut it when you’re dealing with stuff like sudo - it needs to be put through the ringer.

[–] just_another_person@lemmy.world 30 points 4 days ago

Gonna say what I said so many times, and even a few times in this comment section.

ALL.software.has.bugs.

The language doesn't matter. AI doesn't matter. Testing doesn't matter. Every single piece of software will be vulnerable to something eventually.

Staying on top of it is the best you can do.

[–] BB_C@programming.dev 10 points 4 days ago (1 children)

sudo is NOT a part of coreutils. Anyone with basic *nix knowledge would have known this.

sudo-rs, as expected, is also NOT a part of uutils. And the projects happen to be very different in many aspects. uutils started from scratch as a hobby side-project, and it was developed from the start in idiomatic Rust. It can't directly take anything from the GNU implementation anyway, as explained in their README. sudo-rs however is a funded effort to translate some C projects into Rust with as little unsafe{} as possible. Some of the code was directly translated from the original implementation. And if you look at the code in general, you will see that it's rather low-level and looks more like C than Rust in many parts. Some of this is arguably necessary given the nature of sudo functionality, but not all of it.

Both projects do share the fact that they probably didn't push for distros, Ubuntu or anyone else, to switch to either of them by default already, and both were probably surprised it happened this soon.

And yes, this exposure, negative as it may seem for now, is an unavoidable "teething" period, and it's going to be of great benefit to both projects on the long run. Hopefully, Ubuntu users living on the edge wouldn't face too much trouble meanwhile.

(I don't use Ubuntu, but have been using sudo-rs by default for months.)

load more comments (1 replies)

[–] yarr@feddit.nl 10 points 3 days ago (2 children)

I think it's pretty clear the "Rust experiment" has failed. You don't need to be the Amazing Kreskin to know how this plays out. The writing is on the wall: Rust faces a bleak future.

It's time developers got serious and rewrote sudo-rs in a serious, tried-and-true systems language, potentially C or C++. Only then can system administrators sleep soundly at night, feeling safe from the type of bugs introducing Rust to a mature ecosystem can cause.

[–] kilgore_trout@feddit.it 3 points 3 days ago

I hope you are sarcastic, because the issue here is not tha language, but introducing critical software while still in alpha.

[–] quick_snail@feddit.nl 4 points 3 days ago

Hot take. But I won't use rust until they fix the security issue of crates

[–] vrighter@discuss.tchncs.de 4 points 3 days ago (1 children)

but they rewrowe it in rust for safety!

[–] MadhuGururajan@programming.dev 1 points 2 days ago

yo the people railing against this must consider themselves geniuses. It's like people have a hateboner for rust.

Have you considered maybe that this was expected regardless of what language you do it in? It's a rewrite and that's definitely going to miss several decades of changes that have made the normal version good.

You have to measure the time it takes for the rust version to get to the same level as the non-rust counterpart.

Consider also you actually can't switch off your brain because of memory guarantees. You have to work on other important things too.

Also keep a count of CVEs that the rust version generated and decide if the current port is better or a failure.

[–] Aatube@kbin.melroy.org 17 points 4 days ago (1 children)

One of the patches is to prevent the sudo password from being leaked in case of a timeout or sudo being killed. Another patch is to use enum for the feedback parameter. Another patch to ensure feedback is always erased before exiting the read unbuffered code. Another change is also made to not treat backspace as a password character when the password is empty.

[–] arcterus@piefed.blahaj.zone 13 points 4 days ago

As expected, these all sound like logic bugs.

[–] l3db3tt3r@piefed.social 9 points 4 days ago (1 children)

The price of being on the bleeding edge.
But also, trust the process, it's a feature not a bug.

[–] just_another_person@lemmy.world 10 points 4 days ago

ALL software has bugs. Doesn't matter what the language is.

[–] pizza_the_hutt@sh.itjust.works 7 points 4 days ago (1 children)

So glad I'm ditching Ubuntu. Sounds like it's none too soon.

[–] Aatube@kbin.melroy.org 24 points 4 days ago (2 children)

there's regular and then there's LTS releases for a reason

[–] Dagnet@lemmy.world 11 points 4 days ago

ubuntu 24 LTS here and never had an issue. As someone who came from windows and played around with fedora for a while its kinda really surprising.

[–] pizza_the_hutt@sh.itjust.works 9 points 4 days ago (1 children)

The latest LTS release has really old software. The problem here is that the Ubuntu heads are pushing for replacement of core system utilities that aren't ready for prime time. These Rust components need at least another year to cook. This is just the latest bad decision from Ubuntu leadership. See SNAP.

If you want stability, just get Debian. If you need newer software, get an Arch-based distro.

[–] Aatube@kbin.melroy.org 13 points 4 days ago (1 children)

i do use arch

is April 2024 software that old?

replacement of core system utilities that aren't ready for prime time

Could we talk about Unity? I'd wager that these bugs wouldn't have been found by 2027 if Ubuntu hadn't adopted sudo-rs. And I'd say "look at where Unity is right now" if they hadn't switched to GNOME Shell.

[–] caseyweederman@lemmy.ca 4 points 4 days ago

Yeah, fair. And 25.10 is a short-term release anyway. The point of it is to get a running start on 26.04.

[–] sunglocto@lemmy.dbzer0.com 3 points 3 days ago* (last edited 3 days ago)

Literally creating bugs for the sake of creating bugs for no benefits in performance or security. This is completely embarassing.

[–] Mio@feddit.nu 1 points 3 days ago

I just install doas and make alias to it from sudo.

Linux

sudo CVE's from within the last 5 years

CVE-2021-3156 (Severity: High)

CVE-2021-23239

CVE-2021-23240

CVE-2022-43995 (Severity: High)

CVE-2023-7090 (Severity: Medium)

CVE-2023-22809 (Severity: High)

CVE-2023-27320 (Severity: High)

CVE-2023-28486

CVE-2023-28487

CVE-2023-42465

CVE-2025-32462 (Severity: Low)

CVE-2025-32463 (Severity: Critical)

`sudo` CVE's from within the last 5 years