A major vulnerability in Sudo

Posted Feb 3, 2021 8:47 UTC (Wed) by marcH (subscriber, #57642)
Parent article: A major vulnerability in Sudo

> For a bug of this sort to persist for this long in a tool of this nature would seem to indicate that we are not really scrutinizing our code as well as we should be. Or testing and fuzzing enough either.

"We" generally don't find this fun and "we" rarely get paid for any of that either. At least not on the defence side.

People who actually care about memory safety are just moving to safe languages - why would they bother about all this tedious and error-prone review and fuzzing work when that part comes "for free" in newer languages? Every minute of work spent on memory safety is a minute not spent on something more productive - including of course other, higher level security issues.

A major vulnerability in Sudo

Posted Feb 3, 2021 19:02 UTC (Wed) by smoogen (subscriber, #97) [Link] (4 responses)

I would beware of 'it comes for free'. I have seen that argument used over and over for 30 years.. and inevitably found to be flawed... usually because someplace in execution the program has to go into whatever that language 'unsafe' mode is. Then all the security bets are off HOWEVER the programmer and reviewers usually just say 'well it was in XYZ language so it can't be broken'. And then we have reliably 4 years after the language has gotten through the hype cycle of all the security problems that no one fuzzed for.

A major vulnerability in Sudo

Posted Feb 3, 2021 20:12 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (1 responses)

Note that in Rust, many of the "core" crates have comments explaining *why* each and every `unsafe` block is necessary. That makes review of these far easier and more targeted for these kinds of problems. With C and C++, the entire codebase is under such a block and "no one" comments their safety guarantees at that granularity.

A major vulnerability in Sudo

Posted Feb 3, 2021 22:04 UTC (Wed) by marcH (subscriber, #57642) [Link]

> That makes review of these far easier and more targeted for these kinds of problems. With C and C++, the entire codebase is under such a block

Exactly, "git grep unsafe" and win.

This is once again not a yes/no question, it's all about *how much* time is spent in code review and other quality assessments = what every manager say they want but never allocate proper resources for.

And to be clear, when I wrote "it comes for free" I meant _memory safety_ comes for (almost) free. Of course switching to a different programming language is everything but free and even practically impossible for some projects.

A major vulnerability in Sudo

Posted Feb 5, 2021 22:35 UTC (Fri) by ssmith32 (subscriber, #72404) [Link] (1 responses)

Comes for free just means it's more likely to be used, not necessarily it will always be used.

But it's all about risk management anyways, so might as well try to skew the odds in your favor.

A major vulnerability in Sudo

Posted Feb 6, 2021 0:45 UTC (Sat) by marcH (subscriber, #57642) [Link]

No, in this particular context "comes for free" (maybe not the best expression here) means: "it's memory safe or it does not compile".

It's like a static C analyser but built in, not optional and with barely any false positive ever.

A major vulnerability in Sudo

Posted Feb 4, 2021 2:34 UTC (Thu) by plugwash (subscriber, #29694) [Link] (3 responses)

It seems at the moment the price you pay for memory safety is the inability to have shared libraries (at least with "safe" interfaces). So, in addition to the memory/cache costs of duplicate libraries, if one of the libraries does turn out to have a security flaw you have a much bigger job fixing it.

A major vulnerability in Sudo

Posted Feb 4, 2021 6:47 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Nothing at all stops you from making shared libraries with safe interfaces. Swift does that just fine, as an example.

A major vulnerability in Sudo

Posted Feb 4, 2021 17:58 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

A lot of that comes at the expense of overhead in cross-library calls/member lookups. Either you force a function call, have a lookup table of member offsets, or have some weird inline code copying semantics. I believe Rust likely does not want to add such things to the language (at least at this time; it is likely at least in the direction of any likely solution that may appear eventually).

A major vulnerability in Sudo

Posted Feb 4, 2021 9:44 UTC (Thu) by Jonno (subscriber, #49613) [Link]

> It seems at the moment the price you pay for memory safety is the inability to have shared libraries (at least with "safe" interfaces).

Rust does allow you to use the full rust ABI in shared libraries, but the Rust ABI is still unstable between compiler releases. If you want ABI stability you are restricted to the C ABI, which is inherently unsafe. Creating a stable Rust ABI is on the roadmap, but not for anytime soon....