There are two new critical vulnerables found on sudo. And I want to take it as start of a discussion about the question if end user systems still should run sudo at all.
The question also raises, because sudo had 2021 412,000 lines of code (German) and I don’t think it has shrank until now. A goal of doas is to reimplement 95% of sudos functionality within just a few thousands lines of code - which were 4,000 back in 2021. That means it not just 100 times less code, but also much more than 100 times easier to prevent vulnerables and maintain code. CVEs can easily overseen for a whole decade on such a huge amount of code base. Also, a common home user do not need the ability of the last 5% of functionalities sudo has.
So the attack vector becomes much smaller when reducing the amount of code this much. And not only that, the last CVEs need personal access to the device … now we’re using Debian and Arch on mobile end user devices which can be lost or forgotten in trains and busses (one time a phone slipped out of my jeans pocket in a bus - I was just lucky that I could stop the bus to get my phone out). So “getting access to the device” becomes much easier than on desktop computers. And also for police it’s much easier to take away a phone than a computer at your home. In Germany they take phones from refugees etc. So this is a real issue.
On the other hand we already had a short discussion here, where people where saying “there is no review-ability about doas compared to sudo”. On the other hand, at time of that thread doas was 2 years old and the thread is 4.5 years old, so time may has changed something.
Ubuntu also releases sudo-rs (reimplementation of sudo) in 25.10 that increases the security by memory save programming language rust. But memory was no part of the last CVEs, it was a pure logic issue. Still an improvement I would think.
There are also maybe other projects. However it is what I know. And I think it is not a bad idea to switch sudo for something more secure on end user systems, especially for mobile Linux. Not right now to get rid of that CVE, but at some point when the time is just right to switch. What do you think about?
The first question that I would be asking is … what is the 5% of functionality that would be being lost?
Putting that aside, a change from sudo to any other command needs to be done carefully because of the possibility that sudo might be being used in shell scripts. So then questions come up such as … for the 95% of functionality that is in common, is the command line interface identical? Can the “alternatives” mechanism be used in order to give users the choice about sudo implementation?
I totally agree that 4,000 lines of code that gives 95% of the functionality of 400,000 lines of code is a good trade-off, both for reasons of cost and security.
CVE-2025-32462 doesn’t look as if it would impact typical home users anyway. However I understand that you are making a more general point about the security of bloated programs and the desirability of reversing that trend particularly where security is important.
PS A general question about sudo vulnerabilities is … can the vulnerability be exploited without knowing the user’s password i.e. without entering the user’s password? If the answer is “no” then that slightly reduces the severity e.g. the hypothetical lost or stolen mobile device may not be vulnerable to this specific sudo exploit i.e. if you are lucky.
Also note that desktop computers can still be vulnerable in the face of a blended exploit i.e. some other, unrelated exploit (whether social engineering or technical) is used to execute a sudo command as the logged in user, which then uses a vulnerability in sudo to pwn the computer.
The greatest concern would be multi-user computers i.e. where the locally-authenticated attacker can be completely legitimately accessing the computer and yet be untrusted - but that scenario doesn’t match up for most people.
I agree on the general point, but, from the linked vulnerabilities, just for those who didn’t follow the link and may be concerned: Crucially, neither vulnerability can be exploited remotely—an attacker needs local access first. But even with that barrier, it’s still a high-risk scenario considering the prevalence of shared, multi-user environments in modern Linux deployments.
Although I’d err on side of caution, one big question is also what the maintainability and change aspects are - what would the PureOS team think about switching to anything else as it’s not just the change but all the effects it may have to other things and learning about a new thing and how to implement it securely.
I have to confess not knowing about the alternatives as I’ve always relied on sudo. A change might go against muscle memory, hard.
That depends. If the new sudo is just a safer subset of the existing sudo, even if under a new command, then maybe you can use alias - but that’s partly also why I asked about the “alternatives” mechanism.
Ay. And if it’s well reasoned and executed, maybe it’s time to learn a new trick. It’s not like there hasn’t already been learning with L5 (or linux in general), nor will it stop. Besides, using sudo or any alternative means that you are doing something exceptional and something that should not be part of normal daily use and normal user - the less you need to use it, the safer the system (more or less, depending on what you use it for, of course).
That being said, I have no idea. I just read a bit about the idea behind doas. I just think it’s something for administrative work of more complex setups that some organizations would run rather than users for home computing.
That is a danger question. A good one for a specific CVE, but a bad one for a general security approach. In terms of hacking devices it usually needs 5 CVE in average these days to make a root hack successfully (at least I read it somewhere few months ago … while some years ago the situation was much worse). So it means, a device is usually hacked using multiple issues. If you say “this is no issue, because you need the password” you already set a requirement where to search for another CVE.
Let’s say I loose my L5. Police find it. All they need is my sudo PW. The sudo PW is the same as the PIN-code to enter the phone. Police found the device with 10% battery left - early enough before phone shut down and encrypt the data again. Now They see my fingerprints on the screen which are indicating the PIN. So I have already lost. Or there is no fingerprint on screen, they connect the device to a PC and just transfer all data to that new PC. Now they can brute force my sudo PW which is not that strong, because it’s also the PIN of the phone that should be usable quickly. And let’s they police cannot just read the data via USB, because there is a protection … but they have another CVE, that can be used to avoid this protection…
I hope you understand. Most CVEs alone are pretty harmless themselves. But in combination with other issues (whatever they are - even social engineering) they can become dangerous.
And you are true, there are also lots of other CVEs of other programs that can be exploited without even using anything of sudo. But as more there are as higher the possibility one hacker/malware has access to one of those CVEs. If there are less, the risk that the hacker/malware can use one of those is shrinking and that counts a lot.
I’ve found this to annoy me. We really should have a separate pw/pin for locking/unlocking and for sudo. Using sudo (or root level access) password should not be a daily occurrence. It’s just bad security usability, bad design. The only practical mitigation is that there at least is the LUKS encryption pw - if the phone is switched off (and that’s a big if).
As much as I like the point about better security with replacing sudo (if it can be done safely, securely, efficiently etc.), I see that “lockscreen pin” change to be even more important update to overall security with PureOS and L5 (or is it phosh…?).
Maybe let’s discuss this on another thread. I know we had such discussions in the past, but maybe we should push this topic a bit. I just created the sudo topic, because it’s something new to me and as I see, not just to me.
Yes, anyway, for now the article does include info on patches and hardening, so changing isn’t an immediate thing - if those get applied. Which makes this more of a what should be done in the long run thought. So, meybe suggest it for Dawn or E…
I guess my point is “defence in depth”. Yes, sometimes the need for a password will save you and sometimes the need for a password will not save you - but needing a password is still a good thing. It is one layer in your layers of defence.
Where that is true, that is, in my opinion, just a “bug” that needs “fixing” - completely independently of any issues with sudo.
Police find it. Police beat you to a pulp, literally or metaphorically or both, depending on what country you live in, and they have the password anyway.
If that is a realistic threat model for you then you need stronger security e.g. self-destruct (e.g. duress code, or other better options).
For me the realistic threat model is “lost or stolen” - so most likely the person who finds it is not some master hacker or master criminal and is not equipped with the oppressive tools of the state - so basic security (including using LUKS of course) is adequate.
But, for all that, yes, I want sudo to be as secure as possible because it controls some very important functionality!
You did not get my point. I just want to say it should not matter too much if it requires a user password or not to exploit it in terms of how dangerous that CVE is in general. The question only helps end users by making security choices for themselves, but it does not help for to understand the danger of such a CVE. I cannot say “oh cool, it cannot be used as long as nobody knows my PW, I do not need to care about it”.
Realistic, in my country police is allowed to force peoples finger to the phones finger-scanner to unlock the phone and such things. But people have the right to refuse helping them unlocking the device. That means, if the police really wants to get hands on the data, they have to hack it. And so a technical security is the way to go. Other countries, where police is holding a weapon to your head … that’s a totally different story. I’m speaking about a constitutional state.
The sudo-rs project is designed to be a drop in replacement for the original tool. For the vast majority of users, the upgrade should be completely transparent to their workflow. That said, sudo-rs is a not a “blind” reimplementation. The developers are taking a “less is more” approach. This means that some features of the original sudo may not be reimplemented if they serve only niche, or more recently considered “outdated” practices.
So while you are completely correct that broken logic (such as in the two CVEs that you originally cited) will not be helped at all by re-implementation in a memory-safe language, it is still possible that sudo-rs becomes safer in those other ways, depending on which features and practices get dropped out.
The above quote is from May, so if they are really planning on hitting October, I have some doubts. We’ll see.
