Is sudo known to be memory _un_safe? Because otherwise, calling this one "the memory safe [Rust] implementation of Sudo" is a bit weird.
Rust's memory semantics are safe by construction: unless you intentionally write the the part of the language that requires you to explicitly mark things as unsafe, your programs cannot contain the kinds of temporal or spatial memory bugs that can occur in C and C++. Given that, calling this the "memory safe" implementation seems pretty reasonable, in the same way that calling a Java or Python implementation of sudo "memory safe" would also be reasonable.
Sudo before 1.9.5p2 is memory unsafe.
Sudo before 1.8.26 is memory unsafe.
Sudo before 1.6.6 is memory unsafe.
Source: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=sudo
Am I missing something?
And a memory safe language will protect against some overflows on the stack (overflows within frames corrupting other values, rather than errant loops that blow the stack by creating too many frames and/or too large frames).
If you use too much stack space, it terminates the program. It does now however allow for arbitrary code execution like most C compilers do.
The buffer needs to be so large that it not only exceeds the offset to the guard page, but it reaches a non-faulting address. Lastly it needs to be accessed from the front first rather than the back.
I don't know if compilers commonly generate benign memory accesses from the back of the buffer for large stack allocations to get the page fault handler going. I thought that they did after some prominent Linux exploits in this area. If they do do that, this is safe. Also, this issue would also affect the rust compiler, so they must employ that strategy if this works.
I'm sceptical that the chance of introducing new and interesting bugs of other varieties with a rewrite is worth the protection offered by the new environment¹, but either your dismissal of dannymi's point is rather disingenuous or you genuinely were missing something that had been stated quite obviously…
--
[1] except where existing problems are so systemic that fixing them in the original stack would effectively be a partial rewrite anyway, so susceptible to the same risk
Can you please point me to each one of those?
I can only see a few of them.
> memory safe language would have mitigated
potentially, assuming there are no bugs anywhere in the toolchain.
> but either your dismissal of dannymi's point
I wasn't dismissing no one's point.
I simply scrolled through the list of issues and found out that the majority of them were things like (picked them randomly)
systemd before 247 does not adequately block local privilege escalation for some Sudo configurations, e.g., plausible sudoers files in which the "systemctl status" command may be executed. Specifically, systemd does not set LESSSECURE to 1, and thus other programs may be launched from the less program. This presents a substantial security risk when running systemctl from Sudo, because less executes as root when the terminal size is too small to show the complete systemctl output.
An issue was discovered in Zimbra Collaboration (ZCS) 8.8.x and 9.x (e.g., 8.8.15). The Sudo configuration permits the zimbra user to execute the NGINX binary as root with arbitrary parameters. As part of its intended functionality, NGINX can load a user-defined configuration file, which includes plugins in the form of .so files, which also execute as root.
A privilege escalation vulnerability in FortiNAC version below 8.8.2 may allow an admin user to escalate the privileges to root by abusing the sudo privileges.
It was found that cifs-utils' mount.cifs was invoking a shell when requesting the Samba password, which could be used to inject arbitrary commands. An attacker able to invoke mount.cifs with special permission, such as via sudo rules, could use this flaw to escalate their privileges
I am genuinely asking if memory safe languages could prevent this kind of issues, which represent the overwhelming majority of the issues reported on that specific page, and how.
By the magic of find-in-page:
1.9.5p2, CVE-2021-3156
1.8.26, CVE-2019-18634
1.6.6, CVE-2002-0184
1.8.0-to-1.9.12, CVE-2022-43995
I've not read into them in detail, but they are all overflow issues that other languages could have mitigated. Of course they may mitigate them by the task falling over at run-time, but that is “failing safer” than continuing with (potentially deliberately) corrupted data.
---------------------------------
I only spotted the extra details you added when I submitted my first reply (had the reply form open for a while due to work distractions):
> I am genuinely asking if memory safe languages could prevent this kind of issues, which represent the overwhelming majority of the issues reported on that specific page
That page is listing all issues in sudo logged in that database, from which the relevant data was summarised (basically the OP was citing his source). No claim was being made that increased built-in memory safety would prevent all the issues (or even many of them) in that list.
> 1.8.26, CVE-2019-18634
> 1.8.0-to-1.9.12, CVE-2022-43995
interestingly these would not be a problem in a language like Pascal that is not memory safe, but has runtime bounds checks enabled by default or C++ that has flags to enable it
So we are left with one over at least a 100
another interesting thing IMO is that the bugs have been sitting there for a long time, so they are probably not obvious and nobody can be sure there aren't similar sleeping bugs in today's software written in safer languages.
This is not against memory-safe languages, mind you, I prefer Rust over C or C++ any day, I simply found that the original claim seemed too bold compared to the actual data and failed IMO to prove that sudo is ridden by easily exploitable memory bugs.
I'm not seeing that in the list. Of the listed CVEs, not many of them are due to memory safety.
All the versions/ranges listed are associated with relevant CVEs on the list, which of the original posters claims can you not see backed up by that list?
> Of the listed CVEs, not many of them are due to memory safety.
That is a list of all the CVEs for sudo, no claim was made of implied that they were mostly due to issues that memory safety would help with, the poster gave the link as a source for information that was presented.
he literally did
this is the entire message
Sudo 1.8.0 to 1.9.12 (the latter is from 2023(!)) are *memory unsafe*.
Sudo before 1.9.5p2 is *memory unsafe*.
Sudo before 1.8.26 is *memory unsafe*.
Sudo before 1.6.6 is *memory unsafe.*
memory unsafe here is used for dramatic purpose by the author
it actually means that
Sudo 1.8.0 through 1.9.12, with the crypt() password backend, contains a plugins/sudoers/auth/passwd.c *array-out-of-bounds error* that can result in a heap-based buffer over-read. This can be triggered by arbitrary local users with access to Sudo *by entering a password of seven characters or fewer. The impact could vary depending on the system libraries, compiler, and processor architecture.*
in this light, is PHP memory safe because it enforces runtime bounds checks on arrays?
Or
In Sudo before 1.8.26, if pwfeedback is enabled in /etc/sudoers, users can trigger a stack-based buffer overflow in the privileged sudo process. (pwfeedback is a default setting in Linux Mint and elementary OS; however, **it is NOT the default for upstream and many other packages**, and would exist only if enabled by an administrator.)
has one of these bugs ever been exploited?
He literarily, both in the traditional (literally) and modern (figuratively) meanings, did not.
Stating that the page is the source for the information summarised does not mean the same as claiming all/most of the information in the page specifically refers to those cases.
sudo is 43 years old though
> It is written in the extreme YOLO style by people with very poor taste.
Sounds a bit exaggerated to me. Do you happen to have data on this?
How many hundreds of thousands of lines of churn do you think happen per year in sudo?
If your answer is: What do you mean hundreds of thousands? That is the right question, but the wrong answer. The answers being around ~500,000 and on average ~200,000, including this year, respectively.
In contrast, OpenBSD doas, which exists to serve the same primary purpose of executing commands as a super user, clocks in somewhere around a few hundred to maybe 1 or 2 thousand lines total just eyeballing it.
That's my point, sudo survived 43 years, had to support a myriad of different platforms and configurations, doas was started in 2015.
incidentally OpenDoas is written in C too.
We'll see in 35 years how doas is doing.
> In contrast, OpenBSD doas, which exists to serve the same primary purpose of executing commands as a super user, clocks in somewhere around a few hundred to maybe 1 or 2 thousand lines total just eyeballing it.
It seems to me, with those numbers, that the big problem with sudo is not the language it is written in but the extremely large attack surface.
I would guess that for 1 out of every million invocations of sudo, all that extra functionality is needed. For the rest of the time, its merely being used to execute a single command as root.
We could make systems more secure by simply removing sudo from those systems that don't use that extra functionality, and replace it with doas.
Writing security-critical software entirely in C is prima facie evidence of a disqualifying lack of good taste.