| > Can you please point me to each one of those? 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.