The Ubuntu 25.10 transition to using some Rust system utilities continues proving quite rocky. Beyond some early performance issues with Rust Coreutils, breakage for some executables, and broken unattended upgrades due to a Rust Coreutils bug, it’s also sudo-rs now causing Ubuntu developers some headaches. There are two moderate security issues affecting sudo-rs, the Rust version of sudo being used by Ubuntu 25.10.
All non-trivial software has bugs, and it’s unsurprising that in a
sudoimplementation 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
suexclusively and don’t even havesudoinstalled, 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.)
Existing for 60 years makes software a hundred times more secure than the borrow checker
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.
Hot take. But I won’t use rust until they fix the security issue of crates
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 🫣sudoCVE’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 @[email protected] 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”
sudohas 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.
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
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.
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
SendandSynctraits 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.
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).
Yes
Literally creating bugs for the sake of creating bugs for no benefits in performance or security. This is completely embarassing.
Hurray but at least those security vulnerabilities are memory safe!!!
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.
sudois NOT a part ofcoreutils. Anyone with basic *nix knowledge would have known this.sudo-rs, as expected, is also NOT a part ofuutils. And the projects happen to be very different in many aspects.uutilsstarted 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-rshowever is a funded effort to translate some C projects into Rust with as littleunsafe{}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-rsby default for months.)Pardon me for being less intimately familiar with the project - but my point still stands, in terms of test focus. And yes, of course I know bugs are inevitable - I’ve been writing them for damn near two decades at this point.
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.
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.
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.
No…but you were the one trying to twist this exact thing out of context to meet your foolish argument. Same as right now 🤣
Thanks for mentioning that. Block
Whoa whoa whoa this isn’t the Phoronix comment section
Now that you mention it this does sound suspiciously like every Rust-related Phoronix comment section I’ve seen
> deliberately lies about content of article to shit on Rust
> gets called out
> “how dare you twist my words”So fucking childish lol. Could have just used a real article about a Rust vuln like this one but whatever.
At this point I feel like anti-Rust people are more cult-like than any pro-Rust people I’ve met.
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.
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.
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.
Cant tell you how many times Ive heard about curl getting re-written. Same deal.
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)
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.
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, likeinko.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).
To me this says more about Canonical than Rust.
Canonical didn’t make these tools…
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.
They do have a habit of overcommitting to tools that are not yet ready.
Hell, snap still isn’t ready
No it certainly is not.
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++.
b-b-b-but Rust is inherently safe!
Yeah, if you hash your passwords with unsalted md5 it’s much more secure in Rust than PHP!
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.
As expected, these all sound like logic bugs.
The price of being on the bleeding edge.
But also, trust the process, it’s a feature not a bug.ALL software has bugs. Doesn’t matter what the language is.
So glad I’m ditching Ubuntu. Sounds like it’s none too soon.
there’s regular and then there’s LTS releases for a reason
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.
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.
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.
Yeah, fair. And 25.10 is a short-term release anyway. The point of it is to get a running start on 26.04.
