Sudo must be the program with the largest number of buffer overflows I’ve heard about. That news is repeating itself ever since I remember.<p>Maybe a good time to plug doas, a simpler alternative to sudo from OpenBSD folks[1], developed partly due to security fears about sudo. It’s also been ported to Linux and is available in e.g. Alpine and Debian.<p>[1]: <<a href="https://flak.tedunangst.com/post/doas" rel="nofollow">https://flak.tedunangst.com/post/doas</a>>
A fun one. Buffer overflows tend to usually get associated with providing <i>too much</i> data; here's a nice case in which an overflow is triggered by providing <i>too little</i>. Seems like the buffer for storing the password was changed to be dynamically allocated, but only in some parts of the code; other parts still treated it as something that is at least nine bytes long (including the null terminator).<p>In practice, this means that if your password is only one char, then the actual buffer is two bytes long, and the seventh byte past the buffer is then zeroed/set to the null terminator. I wonder if and how this is exploitable.
It looks like this only affects DES passwords. Glibc has supported other hashing algorithms for a very long time and most Linux distros have used them by default for years. I don't think there is a way for an unprivileged user to choose DES if it's not the default, so it's very unlikely this can actually be triggered.
sudo feels like a broken concept to me in general.<p>sudo make install, ok, great, <i>some</i> of the many operations you need to do requires privileges? Better give elevated privileges to all operations!<p>Even worse with GUI: enter your password to install. Now I have absolutely no clue what the scope of sudo is.<p>Of course I don't want to enter my password for all individual cp and mv operations, but if sudo had a better/smaller scope that'd be great.
Why is "sudo 1.8.0 through 1.9.12" affected, but rhel8 shipping sudo 1.8.29 and rhel9 shipping sudo 1.9.5, are not affected?<p><<a href="https://access.redhat.com/security/cve/CVE-2022-43995" rel="nofollow">https://access.redhat.com/security/cve/CVE-2022-43995</a>><p><pre><code> Description:
... Sudo 1.8.0 through 1.9.12 ...
Statement:
The sudo package as distributed with Red Hat Enterprise Linux 7, 8 and 9 is not affected by this issue as it currently doesn't ship the affected code.
</code></pre>
<<a href="https://access.redhat.com/downloads/content/sudo/x86_64/package-latest" rel="nofollow">https://access.redhat.com/downloads/content/sudo/x86_64/pack...</a>><p><pre><code> 1.9.5p2-7.el9
1.8.29-8.el8</code></pre>
Alright, this is getting tiring.<p>Zig, Nim, Rust, D, V, whatever -- can't we just move on from C/C++ already? It's obvious they are not up for the job.
As far as I can tell this is a non-issue. A single byte is written potentially outside a dynamically allocated buffer but the original contents is restored before the function returns (sudo is single-threaded). At best it could be a crash, but even that is unlikely unless using address sanitizer or valgrind.
Seriously, why is sudo so complicated? Most of the time, all sudo has to do is hash a password, check that hash against a file, and if successful, run a program as root.<p>Why can't we just have a minimal version of sudo that does just that and only that so the majority of smaller servers and home users can run sudo without fear of a security bug ever other month? Preferably using the same executable path so that everything else doesn't break.<p>It just seems like most of sudo's security bugs come from weird obscure features almost no one uses. Like that time sudoedit had a security issue. I didn't even know that command existed until it broke things, and it still seems pointless when you can just run "sudo nano" or "sudo vi".