Heap-based buffer overflow in Sudo
41–50 of 328 posts
Re: Heap-based buffer overflow in Sudo
#42Memory safety strikes again, it seems (overflow in a C string due to complex parameter parsing rules).
$ man doas | wc -l
58
$ man doas.conf | wc -l
101
$ man sudo | wc -l
741
$ man sudoers | wc -l
3254
And a bonus: $ man sudoers | grep -C1 despair
The sudoers file grammar will be described below in Extended Backus-Naur
Form (EBNF). Don't despair if you are unfamiliar with EBNF; it is fairly
simple, and the definitions below are annotated.
That only accounts for a small subset of sudo's complexity. It's easily 100x more complex than it needs to be to solve this problem. Now compare the two CVE lists:http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/security/doa...
http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/security/sud...
My reaction to this vulnerability was mild amusement, then later wondering if I should go discredit the inevitable Rust brigade. We don't have to rewrite everything in Rust to get better security. We just have to use simpler tools.
Re: Heap-based buffer overflow in Sudo
#43Turns out that any user could make a root account.
Re: Heap-based buffer overflow in Sudo
#44Re: Heap-based buffer overflow in Sudo
#45Memory safety strikes again, it seems (overflow in a C string due to complex parameter parsing rules).
No, complexity strikes again. I haven't used sudo in years, preferring to use doas now. Its essential code is less than 500 lines and it does everything I've ever used sudo for, and that includes much more than `sudo `. $ man doas | wc -l 58 $ man doas.conf | wc -l 101 $ man sudo | wc -l 741 $ man sudoers | wc -l 3254 And a bonus: $ man sudoers | grep -C1 despair The sudoers file grammar will be described below in Ex…
Yes, it would still be vulnerable to logic errors, like the last famous sudo bug where you pass -1 as the UID. But it wouldn't be vulnerable to this. (And this isn't the first memory safety bug to be found in sudo.)
Yes, sudo's complexity is useless for 99.99% of its users. But wouldn't it be nice if the result were merely a gross feeling rather than a security hole?
Re: Heap-based buffer overflow in Sudo
#46Re: Heap-based buffer overflow in Sudo
#47Is it normal for a security issue of this magnitude to have a 12 day notification period for everyone? That seems... short.
https://oss-security.openwall.org/wiki/mailing-lists/distros...
Re: Heap-based buffer overflow in Sudo
#48Earlier quoted context omitted.
Nope... sudo is just this sudo in 99.99% of the cases. There are some alternatives, such as *bsd's doas, and others, but all but doas and su are so non-popular and outdated that I would not recommend using them, as they probably have way more security issues.
doas is just OpenBSD. You can install doas from ports on NetBSD or FreeBSD, just like you can install doas on Linux. OpenBSD dropped sudo from the base OS several years ago. sudo just became too complex, tailored to the feature creep demanded and required (PAM, ugh ) by Linux users.
Re: Heap-based buffer overflow in Sudo
#49Earlier quoted context omitted.
No, complexity strikes again. I haven't used sudo in years, preferring to use doas now. Its essential code is less than 500 lines and it does everything I've ever used sudo for, and that includes much more than `sudo `. $ man doas | wc -l 58 $ man doas.conf | wc -l 101 $ man sudo | wc -l 741 $ man sudoers | wc -l 3254 And a bonus: $ man sudoers | grep -C1 despair The sudoers file grammar will be described below in Ex…
But if sudo were written in Rust, it could have the same level of complexity and not be vulnerable. Yes, it would still be vulnerable to logic errors, like the last famous sudo bug where you pass -1 as the UID. But it wouldn't be vulnerable to this. (And this isn't the first memory safety bug to be found in sudo.) Yes, sudo's complexity is useless for 99.99% of its users. But wouldn't it be nice if the result were me…
This is not true. Complexity breeds bugs, including security bugs, and memory safety doesn't change that. Your example is a good one - here's another: doas once failed to limit the environment variables which are passed to the child process, which could be used to nefariously influence the program running (e.g. with LD_PRELOAD). How would Rust prevent that oversight? It wouldn't.
A simpler program will generally be more secure than a complicated one, no matter what language either is written in. Furthermore, rewriting an established program from one language to another will always introduce more bugs than it fixes, and more severely the more complex the program is. The single best way to improve security is to reduce the attack surface, and the single best way to do that is to reduce the complexity of your system.
Re: Heap-based buffer overflow in Sudo
#50I don't find bug reports for this in either Debian or Ubuntu bug tracking systems. When do these get entered?