Sudo-rs' first security audit

Sudo-rs' first security audit(ferrous-systems.com)

62 points by Argorak 2 years ago | 59 comments

comex 2 years ago |

> Description: The cargo release build does not strip symbols, so they will be included in the final binary. (..) Impact: Since the code is open source, there is not much information to be gained, but removing these symbols might make reverse engineering of the binary harder.

What a ridiculous finding.

I can try to steelman the argument. Sure, maybe "reverse engineering of the binary" is useless most of the time for an open source project because you can just look at the source code. But if there were hypothetically a memory corruption vulnerability in sudo-rs, then an attacker would want to identify the specific machine code corresponding to the vulnerable source, in order to determine how it could be exploited. That wouldn't be too hard to achieve without symbols, but symbols would definitely make it easier.

Except… even if the binary has symbols stripped, you can just `apt install sudo-rs-dbgsym`, or use debuginfod, to get the full debug info including symbols and DWARF records. Because distros provide that for all their packages. As a feature. To assist debugging.

Even if distros didn't distribute debug symbols, today's security best practices include reproducible builds, which means you should be able to rebuild the package yourself and get the exact same binary, plus the symbols.

So while it might save a tiny bit of disk space to strip the symbols, the security benefit is absolutely nil.

…Well, in theory anyway. In practice, Debian's sudo-rs package seems to be missing both a dbgsym package and reproducible build info. But that's a bug!

Smaug123 2 years ago | |

That is what "low" means as a vulnerability severity! "Low" means "you totally don't need to do anything about this".

The reported property does make the attacker's job slightly harder, after all, since they need to go and work out where the symbols are rather than just having them right there in front of them.

comex 2 years ago | | |

The problem with the report isn’t just that it’s minor. The problem is that it’s directionally wrong. If the change makes life even slightly harder for attackers, then it makes life harder to exactly the same extent for legitimate users trying to debug their programs. The fact that debuginfo is widely distributed demonstrates that distros prioritize the benefits of debuggability over the benefits of obscurity, and there’s no reason that weighting should be different in the small versus in the large. So, if security and debuggability were the only concerns, debuggability should win and distro binaries should never be stripped. It just so happens that there is an unrelated concern, disk space, that justifies stripping them anyway, but that doesn’t justify characterizing the lack of stripping as a security flaw, not even an incredibly minor one.

kaba0 2 years ago | |

> Even if distros didn't distribute debug symbols, today's security best practices include reproducible builds, which means you should be able to rebuild the package yourself and get the exact same binary, plus the symbols

Well, that’s why binary randomization/fuzzing is an important security research topic. If everyone would be running semantically identical, but not binary-identical programs, a ROP-based vulnerability would not be able to spread across computers, or in absence of the correct binary on the target device, it would be infeasible.

GauntletWizard 2 years ago | | |

This is the very definition of security through obscurity. If everyone were running "semantically identical, but not binary-identical programs" there would be debugging tools to automatically patch your patches for each target device.

Kab1r 2 years ago | |

You could also always compile it from source with the debug symbols even if it wasn't provided by a distro.

mtlmtlmtlmtl 2 years ago | |

If you can apt-get stuff, why would you be trying to exploit sudo? Even assuming apt-get was the only thing you could run as root, that would essentially allow arbitrary filesystem changes anyway. Escalating to full root from that would be trivial.

kaba0 2 years ago | | |

You can do that on an identical system you have access to. Then you discover the necessary vulnerability and apply it on the target system.

codetrotter 2 years ago | | |

You don’t need to be root to retrieve the debug symbols from apt if the debug symbols were in the apt repository

Something like

    apt-get download sudo-rs-dbgsym

    mkdir -p ~/tmp/

    dpkg -x sudo-rs-dbgsym.deb ~/tmp/

should provide what you need I think

3c6bYDXLMj 2 years ago | |

Come off it. That’s what the severity rating is for. Anyone used to reading these sorts of reports comes to expect these things. And someone saying “all you have to do, is simply…” doesn’t change the fact that there’s suddenly more effort involved.

aliceryhl 2 years ago |

I'm surprised that CLN-003 made the list even as low severity. It's intended to make reverse engineering of the binary harder, but the code is already freely accessible (and CLN-003 also acknowledges this).

RcouF1uZ4gsC 2 years ago | |

That vulnerability seems like something added to adhere to the rule of 3. In at least Western culture, we have this ingrained thing for groups of 3 - for example Trinity, 3 point outline, 3 sentences in a paragraph etc.

It seems like this was picked to end up with 3 vulnerabilities so the security researchers can feel they did a complete job.

thiht 2 years ago | |

I see it as a note to be exhaustive. It’s the kind of thing if you don’t add it to your report, some smart ass WILL say something like « actually they forgot about the bin symbols, how could they miss this? ». There’s always someone like this.

g-b-r 2 years ago |

The arbitrary delete vulnerability scared me at first, but are there really situations where a non-root user can create a new user??

mtlmtlmtlmtl 2 years ago | |

In practice, I doubt it. But sudo offers highly granular permission controls. You can permit a user to only run certain commands as root. So it is a real vuln in the sense that if you give someone that ability, you've now given them more than intended.

cedws 2 years ago |

I just ran tokei in the sudo-rs repository and there's over 28,000 lines of code not including whitespace. The Rust rewrite is a good step forward but we should really be asking ourselves if we need all this complexity in something so critical.

OpenBSD's doas is 108 lines of C. sudo and doas are not equivalent in functionality, but it shows how simple things can really be.

https://github.com/openbsd/src/blob/master/distrib/special/d...

0xbadcafebee 2 years ago |

  CLN-001: relative path traversal vulnerability (moderate)

  During the audit, it came to light that the original sudo implementation was also affected by this issue, although with a lower security severity due to their use of the openat function.

I thought Rust was secure? How is it possible to write a program in Rust and still have the same security vulnerabilities, and actually be higher severity?

It's almost as if changing to an entirely new programming language and ecosystem isn't enough to make a secure application, and that you still have to try hard to secure it, regardless of the language.

How interesting.

ncallaway 2 years ago | |

> It's almost as if changing to an entirely new programming language and ecosystem isn't enough to make a secure application, and that you still have to try hard to secure it, regardless of the language.

Has anyone argued that switching to Rust alone is sufficient to stop all security vulnerabilities?

Has anyone suggested that switching to Rust means you no longer need to do any work to write secure applications?

It seems to me you're arguing against a totally self-constructed straw-man.

dataking 2 years ago | |

This is a logic error whereas Rust delivers a way to drive down memory errors (assuming parent comment isn't mocking Rust advocates).

viraptor 2 years ago | |

That's a low quality troll. Nobody was saying rust solves all security issues.

0xbadcafebee 2 years ago | | |

It's hilarious that people invented an entirely new language to prevent a single attack vector. That's like learning Perl because it has no buffer overflows.