| > That each of the versions dannymi listed had at least one potentially exploitable 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.