The original announcement email does a much better job of explaining the actual vulnerability, and the configuration under which its an issue (using ALL and !ro

The original announcement email does a much better job of explaining the actual vulnerability, and the configuration under which its an issue (using ALL and !root in the runas part of the sudoers entry) https://www.openwall.com/lists/oss-security/2019/10/14/1 https://www.openwall.com/lists/oss-security/2019/10/14/1 This writeup does little to explain the issue beyond showing a config line that is vulnerable (but doesn't really explain which part makes it vulnerable). It also incorrectly states the issue is sudo failing to parse the value correctly. > the function fails to parse all values correctly and when giving the parameter user id “-1” or its unsigned number “4294967295”, the command will run as root, bypassing the security policy entry we set in the example above. Which is incorrect, sudo parses the value just fine, the issue comes from the `setresuid` and `setreuid` calls. Both treat -1 as a special case that means the corresponding value should not be modified.[0][1] I mean, sure this article gets the key point that -u#-1 gets you root, but if you're explaining a vulnerability I'd expect the technical details to be correct. [0] http://man7.org/linux/man-pages/man2/setresuid.2.html http://man7.org/linux/man-pages/man2/setresuid.2.html [1] http://man7.org/linux/man-pages/man2/setreuid.2.html http://man7.org/linux/man-pages/man2/setreuid.2.html