A newly discovered and serious flaw in the sudo command can, if exploited, enable users to run commands as root in spite of the fact that the syntax of the /etc/sudoers file specifically disallows them from doing so.
Updating sudo to version 1.8.28 should address the problem, and Linux admins are encouraged to do so as soon as possible.
How the flaw might be exploited depends on specific privileges granted in the /etc/sudoers file. A rule that allows a user to edit files as any user except root, for example, would actually allow that user to edit files as root as well. In this case, the flaw could lead to very serious problems.
For a user to exploit the flaw, a user needs to be assigned privileges in the /etc/sudoers file that allow that user to run commands as some other users, and the flaw is limited to the command privileges that are assigned in this way.
This problem affects versions prior to 1.8.28. To check your sudo version, use this command:
$ sudo -V Sudo version 1.8.27 <=== Sudoers policy plugin version 1.8.27 Sudoers file grammar version 46 Sudoers I/O plugin version 1.8.27
The vulnerability has been assigned CVE-2019-14287 in the Common Vulnerabilities and Exposures database. The risk is that any user who has been given the ability to run even a single command as an arbitrary user may be able to escape the restrictions and run that command as root – even if the specified privilege is written to disallow running the command as root.
The lines below are meant to give the user "jdoe" the ability to edit files with vi as any user except root (!root means "not root") and nemo the right to run the id command as any user except root:
# affected entries on host "dragonfly" jdoe dragonfly = (ALL, !root) /usr/bin/vi nemo dragonfly = (ALL, !root) /usr/bin/id
However, given the flaw, either of these users would be able to circumvent the restriction and edit files or run the id command as root as well.
The flaw can be exploited by an attacker to run commands as root by specifying the user ID "-1" or "4294967295."
The response of "1" demonstrates that the command is being run as root (showing root's user ID).
Joe Vennix from Apple Information Security both found and analyzed the problem.