5 ms·

Sudo 1.8.0 to 1.9.12 (the latter is from 2023(!)) are memory unsafe. Sudo before 1.9.5p2 is memory unsafe. Sudo before 1.8.26 is memory unsafe. Sudo before 1

Sudo 1.8.0 to 1.9.12 (the latter is from 2023(!)) are memory unsafe. Sudo before 1.9.5p2 is memory unsafe. Sudo before 1.8.26 is memory unsafe. Sudo before 1.6.6 is memory unsafe. Source: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=sudo https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=sudo

peoplefromibiza 3y ago
most of the issues linked are not memory related. Am I missing something?
- iknowstuff 3y ago
  You’re missing the ones that are
  - c_crank 3y ago
    Only six entries mention overflows, only half of those involve the heap.
    - dspillett 3y ago
      A number of those entries reference multiple overflows. And a memory safe language will protect against some overflows on the stack (overflows within frames corrupting other values, rather than errant loops that blow the stack by creating too many frames and/or too large frames).
      - c_crank 3y ago
        Yeah, if you really wanted to be extra super secure, you can always rewrite it in Java or something.
      - gpm 3y ago
        Rust will protect against all overflows on the stack (up to compiler bugs, tier 2 and lower platforms do not necessarily get this guarantee). If you use too much stack space, it terminates the program. It does now however allow for arbitrary code execution like most C compilers do.
        asveikau 3y ago
        Are you aware of what an exploitable scenario of using too much stack space looks like? The buffer needs to be so large that it not only exceeds the offset to the guard page, but it reaches a non-faulting address. Lastly it needs to be accessed from the front first rather than the back. I don't know if compilers commonly generate benign memory accesses from the back of the buffer for large stack allocations to get the page fault handler going. I thought that they did after some prominent Linux exploits in this area. If they do do that, this is safe. Also, this issue would also affect the rust compiler, so they must employ that strategy if this works.
- dspillett 3y ago
  That each of the versions dannymi listed had at least one potentially exploitable issue that a natively memory safe language would have mitigated, versions actively used in production as recently as this year even by people who keep bang up-to-date? I'm sceptical that the chance of introducing new and interesting bugs of other varieties with a rewrite is worth the protection offered by the new environment¹, but either your dismissal of dannymi's point is rather disingenuous or you genuinely were missing something that had been stated quite obviously… -- [1] except where existing problems are so systemic that fixing them in the original stack would effectively be a partial rewrite anyway, so susceptible to the same risk
  - peoplefromibiza 3y ago
    > 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.

peoplefromibiza 3y ago

most of the issues linked are not memory related. Am I missing something?

iknowstuff 3y ago
You’re missing the ones that are
- c_crank 3y ago
  Only six entries mention overflows, only half of those involve the heap.
  - dspillett 3y ago
    A number of those entries reference multiple overflows. And a memory safe language will protect against some overflows on the stack (overflows within frames corrupting other values, rather than errant loops that blow the stack by creating too many frames and/or too large frames).
    - c_crank 3y ago
      Yeah, if you really wanted to be extra super secure, you can always rewrite it in Java or something.
    - gpm 3y ago
      Rust will protect against all overflows on the stack (up to compiler bugs, tier 2 and lower platforms do not necessarily get this guarantee). If you use too much stack space, it terminates the program. It does now however allow for arbitrary code execution like most C compilers do.
      - asveikau 3y ago
        Are you aware of what an exploitable scenario of using too much stack space looks like? The buffer needs to be so large that it not only exceeds the offset to the guard page, but it reaches a non-faulting address. Lastly it needs to be accessed from the front first rather than the back. I don't know if compilers commonly generate benign memory accesses from the back of the buffer for large stack allocations to get the page fault handler going. I thought that they did after some prominent Linux exploits in this area. If they do do that, this is safe. Also, this issue would also affect the rust compiler, so they must employ that strategy if this works.
dspillett 3y ago
That each of the versions dannymi listed had at least one potentially exploitable issue that a natively memory safe language would have mitigated, versions actively used in production as recently as this year even by people who keep bang up-to-date? I'm sceptical that the chance of introducing new and interesting bugs of other varieties with a rewrite is worth the protection offered by the new environment¹, but either your dismissal of dannymi's point is rather disingenuous or you genuinely were missing something that had been stated quite obviously… -- [1] except where existing problems are so systemic that fixing them in the original stack would effectively be a partial rewrite anyway, so susceptible to the same risk
- peoplefromibiza 3y ago
  > 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.