A new and serious flaw in the sudo command is discovered which can be exploited, enabling users to run commands as root even if the syntax of the /etc/sudoers file specifically disallows them from doing so.
By updating the sudo to version 1.8.28 should solve the problem, and Linux administrators are encouraged to do so as soon as possible.
The flaw might be exploited depending 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 such cases the security flaw can lead to very serious security 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 the new 1.8.28 version. You can check your sudo version by simply entering the command:
sudo -V
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 "nitrax" 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" nitrax 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 idcommand 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 had found and analyzed the problem.