Sudo 1.6.9 before 1.8.5, when envreset is disabled, does not properly check environment variables for the envdelete restriction, which allows local users with sudo permissions to bypass intended command restrictions via a crafted environment variable.
Anders Kaseorg and Evan Broder reported a flaw in the way sudo handled duplicated environment variables. When sudo set certain environment variables (such as PATH set to securepath value, or special sudo environment variables SUDO), the value overwrote first value from user's environment (if it had been preserved and had not removed previously due to envreset / envkeep / envdelete settings), but left following environment variables with the same name unchanged.
This problem can be used to override securepath setting from /etc/sudoers file for shell scripts executed using sudo, as bash uses last PATH environment variable value. In configurations where securepath is used to enforce sane PATH setting for shell scripts, this can allow users with the privileges to run some script using sudo to run arbitrary command with the privileges of the target user.
Upstream fixes to handle duplicated environment variables: http://www.sudo.ws/repos/sudo/rev/3057fde43cf0 http://www.sudo.ws/repos/sudo/rev/a09c6812eaec
This issue affects sudo packages shipped in Red Hat Enterprise Linux 5, however not the default configuration. In default configuration, no securepath is set. envreset is used by default, and PATH is not preserved during the environment reset (unlike the upstream sudo default).
The sudo packages in Red Hat Enterprise Linux 3 and 4 do not allow setting securepath in the /etc/sudoers, there is no compile-time default for the securepath either. Whether the user PATH setting is preserved depends on envreset / envdelete configuration.
Current Fedora configuration specifies securepath, but also removes PATH from the environment by default.
sudo 1.6.x before 1.6.9p21 and 1.7.x before 1.7.2p4, when a pseudo-command is enabled, permits a match between the name of the pseudo-command and the name of an executable file in an arbitrary directory, which allows local users to gain privileges via a crafted executable file, as demonstrated by a file named sudoedit in a user's home directory.
The command matching functionality in sudo 1.6.8 through 1.7.2p5 does not properly handle when a file in the current working directory has the same name as a pseudo-command in the sudoers file and the PATH contains an entry for ".", which allows local users to execute arbitrary commands via a Trojan horse executable, as demonstrated using sudoedit, a different vulnerability than CVE-2010-0426.
A security flaw was found in the way Sudo performed matching for user described by a password against the list of members, allowed to run particular sudo command, when the group option was specified on the command line. If a local, unprivileged user was authorized by sudoers file to run their sudo commands with permissions of a particular group (different to their own), it could lead to privilege escalation (execution of that sudo command with permissions of privileged user account (root)).
Acknowledgements:
Red Hat would like to thank Markus Wuethrich of Swiss Post - PostFinance for reporting this issue.