> Description: The cargo release build does not strip symbols, so they will be included in the final binary. (..) Impact: Since the code is open source, there is not much information to be gained, but removing these symbols might make reverse engineering of the binary harder.<p>What a ridiculous finding.<p>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 <i>would</i> 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.<p>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.<p>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.<p>So while it might save a tiny bit of disk space to strip the symbols, the security benefit is absolutely nil.<p>…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!
I'm surprised that CLN-003 made the list even as low severity. It's intended to make reverse engineering of the binary harder, but the code is already freely accessible (and CLN-003 also acknowledges this).
I just ran tokei in the sudo-rs repository and there's over 28,000 lines of code not including whitespace. The Rust rewrite is a good step forward but we should really be asking ourselves if we need all this complexity in something so critical.<p>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.<p><a href="https://github.com/openbsd/src/blob/master/distrib/special/doas/doas.c">https://github.com/openbsd/src/blob/master/distrib/special/d...</a>
<p><pre><code> 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.
</code></pre>
I thought Rust was secure? How is it possible to write a program in Rust and still have the same security vulnerabilities, and actually be higher severity?<p>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.<p>How interesting.