What a ridiculous finding.
I can try to steelman the argument. Sure, maybe "reverse engineering of the binary" is useless most of the time for an open source project because you can just look at the source code. But if there were hypothetically a memory corruption vulnerability in sudo-rs, then an attacker would want to identify the specific machine code corresponding to the vulnerable source, in order to determine how it could be exploited. That wouldn't be too hard to achieve without symbols, but symbols would definitely make it easier.
Except… even if the binary has symbols stripped, you can just `apt install sudo-rs-dbgsym`, or use debuginfod, to get the full debug info including symbols and DWARF records. Because distros provide that for all their packages. As a feature. To assist debugging.
Even if distros didn't distribute debug symbols, today's security best practices include reproducible builds, which means you should be able to rebuild the package yourself and get the exact same binary, plus the symbols.
So while it might save a tiny bit of disk space to strip the symbols, the security benefit is absolutely nil.
…Well, in theory anyway. In practice, Debian's sudo-rs package seems to be missing both a dbgsym package and reproducible build info. But that's a bug!
The reported property does make the attacker's job slightly harder, after all, since they need to go and work out where the symbols are rather than just having them right there in front of them.
Well, that’s why binary randomization/fuzzing is an important security research topic. If everyone would be running semantically identical, but not binary-identical programs, a ROP-based vulnerability would not be able to spread across computers, or in absence of the correct binary on the target device, it would be infeasible.
Something like
apt-get download sudo-rs-dbgsym
mkdir -p ~/tmp/
dpkg -x sudo-rs-dbgsym.deb ~/tmp/
It seems like this was picked to end up with 3 vulnerabilities so the security researchers can feel they did a complete job.
OpenBSD's doas is 108 lines of C. sudo and doas are not equivalent in functionality, but it shows how simple things can really be.
https://github.com/openbsd/src/blob/master/distrib/special/d...
The fabulous article mentions that, “sudo-rs only has 3 dependencies in its dependency graph” so maybe they could trade loc for deps but that doesn’t seem wise to me.
The audit found one moderate path traversal vulnerability which was also present in og sudo, so I’m not sure how your suggestion could be made practical.
All of it. Seriously. doas demonstrates that sudo's primary function (running commands as another user) can be achieved in an order of magnitude less code and a significantly smaller attack surface.
90% of people don't need more than that, they don't need all the bells and whistles that sudo offers. We aren't in the 90s running on mainframes anymore.
As an aside, doas and sudo are conceptually broken from a security POV because the user's shell can be played with to elevate privileges. The real fix is dump doas and sudo entirely.
The real question is, do you really need everything that sudo can do? Or would doas be sufficient?
On my FreeBSD servers, I install doas instead of sudo, and I have never once found myself missing any features in spite of having completely replaced sudo with doas on my FreeBSD servers.
Replaced as in, I no longer even have sudo installed on my FreeBSD servers. I switched from sudo to doas cold turkey years ago and haven’t looked back.
(On Linux I still use sudo, but that is simply because it comes pre-installed on the Linux distros I use so I haven’t bothered to install doas instead there.)
doas does exactly what I need; run the following command as root.
I more surprised an os would let you make a user with "../../" in the name though. I'd bet a heap of things would break. A while back I saw a guy name his windows desktop with an emoji and all sorts of software fell over.
Still just a tidy 1072 lines in that folder though.
I spent 5 minutes staring at your file trying to understand how on earth it does the things in the man page, but of course it doesn’t.
However, there are about six billion* things in existence right now that use sudo, so it’s a good idea to make sudo safer as well.
* rhetorical statistic
What is all the complexity? What is all the extra functionality that sudo offers?
The "Examples" section of the sudoers(5) man page is probably a good place to start to get an idea of the sorts of ways it can be configured
https://manpages.debian.org/bookworm/sudo/sudoers.5.en.html#...
Simple isn't always better.
CLN-001: relative path traversal vulnerability (moderate)
During the audit, it came to light that the original sudo implementation was also affected by this issue, although with a lower security severity due to their use of the openat function.
It's almost as if changing to an entirely new programming language and ecosystem isn't enough to make a secure application, and that you still have to try hard to secure it, regardless of the language.
How interesting.
Has anyone argued that switching to Rust alone is sufficient to stop all security vulnerabilities?
Has anyone suggested that switching to Rust means you no longer need to do any work to write secure applications?
It seems to me you're arguing against a totally self-constructed straw-man.