9 ms·

I am not sure if memory-safety is the biggest issue in sudo design. I find the fact that it is a setuid binary a much bigger issue because a bug can possible re

by kokada 1y ago

I am not sure if memory-safety is the biggest issue in sudo design. I find the fact that it is a setuid binary a much bigger issue because a bug can possible result in privilege escalation. I found an alternative implementation that doesn't rely in being a setuid binary like systemd-run0 much more interesting from a security perspective, but I am no security expert.

deleted 1y ago
[deleted]
Retr0id 1y ago
A bug in a daemon-based sudo alternative would surely also result in privilege escalation? I think the main benefit of eliminating setuid binaries is that you can forbid them system-wide (e.g. via mount flags), as a hardening measure.
- JoshTriplett 1y ago
  There's value in always starting processes from a known-secure environment rather than attempting to transform a user's arbitrary environment into a secure one.
  - Retr0id 1y ago
    True, CVE-2021-4034 comes to mind as a recent example (exploiting zero-length argv)
    - hedora 1y ago
      How is that any different than a daemon that has a parser error in its message handler, except that the daemon could be misconfigured to listen on a network socket? The original unix process abstraction was extremely simple; the entire spec is a few pages. The problem is that Linux keeps adding more and more levels of Rube Goldberg machine to its security model, so now literally no one understands how a default minimal install of, say, Ubuntu works. Adding a magic daemon that runs stuff as root to this pile of complexity probably won’t help. Ripping out almost all the cruft that’s accumulated over the years, and adding back something sane (maybe BSD jails) would work a lot better.
      - Dylan16807 1y ago
        > How is that any different than a daemon that has a parser error in its message handler The non-daemon has to parse just as much in addition to making itself secure. Actually it needs to parse more things in more complex ways.
        hedora 1y ago
        Assuming static linkage (which sudo has to assume), there’s really not much to parse. It should just be dealing with a null-delimited list (argv) and the caller’s environment variables (which it just needs to ignore and clear by default). Here’s a simple implementation: https://github.com/TheMilkies/rut/blob/main/rut.c https://github.com/TheMilkies/rut/blob/main/rut.c (Though it doesn’t clear the environment unless I’m missing something - they should probably replace the call to execvp with one to execvpe, and add a null pointer to the end of the argument list). The problem of setting up root’s environment and parsing the command line is left to the shell in both solutions (the thing I linked doesn’t indirect through a root login shell). There’s also the config file, but that’s the same for both. Similarly, the system could be running some SEL derivative or be using a capability system that causes non-standard behavior from system calls, but the daemon has the same problem.
- kokada 1y ago
  I think this post explains why much better than I can: https://mastodon.social/@pid_eins/112353324518585654 https://mastodon.social/@pid_eins/112353324518585654. So yes, I am not saying that privilege escalation bugs are impossible if you have a different architecture, but like Lennart argues is that it makes them much more difficult to happen, especially because creating a proper setuid is difficult. Also there is a bunch of things that makes sudo especially tricky to implement correctly.
MajesticHobo2 1y ago
Right, but now the vector for privilege escalation will have to be a logic bug in memory-safe sudo instead of either a memory corruption (see CVE-2021-3156) or a logic bug. It’s hard not to see this as a major improvement.
- charcircuit 1y ago
  Being a setuid binary means that sudo also suffers from attacks where an attacker runs `sudo ./malware` and then convinces the user to authenticate. Depending on how sudo authenticates phishing attacks or password reuse from another breach can be used to escalate privileges.
  - jvanderbot 1y ago
    Those will also have to be fixed/considered, but do not detract from the contribution of removing memory safety bugs which may enable exploits.
    - charcircuit 1y ago
      This is a case of doubling down on bad design. To me it's wasted effort preventing theoretical bugs in niche setups.
      - a_t48 1y ago
        Even with a new, perfect paradigm, there would be billions of systems running sudo for years.
      - jvanderbot 1y ago
        I think the opposing view is that moving away from sudo is substantially more effort and would break basically everything to accomplish "the same" thing as robustifying sudo (for some very loose definition of "same")
        charcircuit 1y ago
johnisgood 1y ago
Rust version of sudo had lots of ridiculous logic bugs. I do not see the improvement.
- TrueDuality 1y ago
  Do you have an example of the logic bugs you're referring to?
  - johnisgood 1y ago
    I am pretty sure it is around here somewhere: https://github.com/trifectatechfoundation/sudo-rs/issues https://github.com/trifectatechfoundation/sudo-rs/issues. I apologize, I do not bookmark these issues, but maybe I should start doing that? In any case, you will find logic bugs which may raise the question "is it really worth the rewrite?".
    - internetter 1y ago
      You have the burden of proof to substantiate your accusations. Until then they're entirely unfounded.
      - butlike 1y ago
        Aren't full rewrites pretty much universally considered harmful?
        tcfhgj 1y ago
        No
        johnisgood 1y ago
        Not universally, but often it introduces logic bugs that the original project did not have. I guess it heavily depends. In this case, I think it may do more harm than good. Just use "doas" or something. FWIW, I trust "sudo" more than "sudo-rs".
musicale 1y ago
I used to be annoyed that sudo would reliably crash from memory errors. Eventually the bug (and associated vulnerability) was patched. I think.

by kokada 1y ago

deleted 1y ago

[deleted]

Retr0id 1y ago

A bug in a daemon-based sudo alternative would surely also result in privilege escalation? I think the main benefit of eliminating setuid binaries is that you can forbid them system-wide (e.g. via mount flags), as a hardening measure.

JoshTriplett 1y ago
There's value in always starting processes from a known-secure environment rather than attempting to transform a user's arbitrary environment into a secure one.
- Retr0id 1y ago
  True, CVE-2021-4034 comes to mind as a recent example (exploiting zero-length argv)
  - hedora 1y ago
    How is that any different than a daemon that has a parser error in its message handler, except that the daemon could be misconfigured to listen on a network socket? The original unix process abstraction was extremely simple; the entire spec is a few pages. The problem is that Linux keeps adding more and more levels of Rube Goldberg machine to its security model, so now literally no one understands how a default minimal install of, say, Ubuntu works. Adding a magic daemon that runs stuff as root to this pile of complexity probably won’t help. Ripping out almost all the cruft that’s accumulated over the years, and adding back something sane (maybe BSD jails) would work a lot better.
    - Dylan16807 1y ago
      > How is that any different than a daemon that has a parser error in its message handler The non-daemon has to parse just as much in addition to making itself secure. Actually it needs to parse more things in more complex ways.
      - hedora 1y ago
        Assuming static linkage (which sudo has to assume), there’s really not much to parse. It should just be dealing with a null-delimited list (argv) and the caller’s environment variables (which it just needs to ignore and clear by default). Here’s a simple implementation: https://github.com/TheMilkies/rut/blob/main/rut.c https://github.com/TheMilkies/rut/blob/main/rut.c (Though it doesn’t clear the environment unless I’m missing something - they should probably replace the call to execvp with one to execvpe, and add a null pointer to the end of the argument list). The problem of setting up root’s environment and parsing the command line is left to the shell in both solutions (the thing I linked doesn’t indirect through a root login shell). There’s also the config file, but that’s the same for both. Similarly, the system could be running some SEL derivative or be using a capability system that causes non-standard behavior from system calls, but the daemon has the same problem.
kokada 1y ago
I think this post explains why much better than I can: https://mastodon.social/@pid_eins/112353324518585654 https://mastodon.social/@pid_eins/112353324518585654. So yes, I am not saying that privilege escalation bugs are impossible if you have a different architecture, but like Lennart argues is that it makes them much more difficult to happen, especially because creating a proper setuid is difficult. Also there is a bunch of things that makes sudo especially tricky to implement correctly.

MajesticHobo2 1y ago

Right, but now the vector for privilege escalation will have to be a logic bug in memory-safe sudo instead of either a memory corruption (see CVE-2021-3156) or a logic bug. It’s hard not to see this as a major improvement.

charcircuit 1y ago
Being a setuid binary means that sudo also suffers from attacks where an attacker runs `sudo ./malware` and then convinces the user to authenticate. Depending on how sudo authenticates phishing attacks or password reuse from another breach can be used to escalate privileges.
- jvanderbot 1y ago
  Those will also have to be fixed/considered, but do not detract from the contribution of removing memory safety bugs which may enable exploits.
  - charcircuit 1y ago
    This is a case of doubling down on bad design. To me it's wasted effort preventing theoretical bugs in niche setups.
    - a_t48 1y ago
      Even with a new, perfect paradigm, there would be billions of systems running sudo for years.
    - jvanderbot 1y ago
      I think the opposing view is that moving away from sudo is substantially more effort and would break basically everything to accomplish "the same" thing as robustifying sudo (for some very loose definition of "same")
      - charcircuit 1y ago

johnisgood 1y ago

Rust version of sudo had lots of ridiculous logic bugs. I do not see the improvement.

TrueDuality 1y ago
Do you have an example of the logic bugs you're referring to?
- johnisgood 1y ago
  I am pretty sure it is around here somewhere: https://github.com/trifectatechfoundation/sudo-rs/issues https://github.com/trifectatechfoundation/sudo-rs/issues. I apologize, I do not bookmark these issues, but maybe I should start doing that? In any case, you will find logic bugs which may raise the question "is it really worth the rewrite?".
  - internetter 1y ago
    You have the burden of proof to substantiate your accusations. Until then they're entirely unfounded.
    - butlike 1y ago
      Aren't full rewrites pretty much universally considered harmful?
      - tcfhgj 1y ago
        No
        johnisgood 1y ago
        Not universally, but often it introduces logic bugs that the original project did not have. I guess it heavily depends. In this case, I think it may do more harm than good. Just use "doas" or something. FWIW, I trust "sudo" more than "sudo-rs".

musicale 1y ago

I used to be annoyed that sudo would reliably crash from memory errors. Eventually the bug (and associated vulnerability) was patched. I think.