- #Cve 2019 14287 exploit update#
- #Cve 2019 14287 exploit verification#
- #Cve 2019 14287 exploit software#
- #Cve 2019 14287 exploit password#
#Cve 2019 14287 exploit update#
NOTE: This line indicates an update has been released for the listed product(s). SUSE Linux Enterprise Server for SAP 12-SP3 (src): sudo-1.8.20p2-3.14.1
#Cve 2019 14287 exploit software#
SUSE Linux Enterprise Software Development Kit 12-SP4 (src): sudo-1.8.20p2-3.14.1
SUSE-SU-2019:2666-1: An update that fixes one vulnerability is now available. Joe Vennix from Apple Information Security found and analyzed the bug. Any attempt to run the command as a different user will be denied. In this example, alice is only allowed to run the id command as root. For example, the following sudoers entry is unaffected: Only sudoers entries where the ALL keyword is present in the Runas specifier are affected. However, due to the bug, bob is actually able to run vi as root by running sudo -u#-1 vi, violating the security policy. User bob is allowed to run vi as any user but root. For example, given the following sudoers entry: If a sudoers entry is written to allow the user to run a command as any user except root, the bug can be used to avoid this restriction.
#Cve 2019 14287 exploit password#
Additionally, because the user ID specified via the -u option does not exist in the password database, no PAM session modules will be run. This results in sudo log entries that report the command as being run by user ID 4294967295 and not root (or user ID 0). This is because the sudo command itself is already running as user ID 0 so when sudo tries to change to user ID -1, no change occurs. However, the setresuid(2) and setreuid(2) system calls, which sudo uses to change the user ID before running the command, treat user ID -1 (or its unsigned equivalent 4294967295), specially and do not change the user ID for this value. Not only is user is able to run the id command as any valid user, she is also able to run it as an arbitrary user ID by using the #uid syntax, for example: For example, the following sudoers entry allow the id command to be run as any user because it includes the ALL keyword in the Runas specifier. Sudo supports running a command with a user-specified user name or user ID, if permitted by the sudoers policy. Typically, this means that the user's sudoers entry has the special value ALL in the Runas specifier.
This vulnerability has been assigned CVE-2019-14287 in the Common Vulnerabilities and Exposures database.Įxploiting the bug requires that the user have sudo privileges that allow them to run commands with an arbitrary user ID. Sudo versions prior to 1.8.28 are affected. In addition, PAM session modules will not be run for the command. Log entries for commands run this way will list the target user as 4294967295 instead of root. This can be used by a user with sufficient sudo privileges to run commands as root even if the Runas specification explicitly disallows root access as long as the ALL keyword is listed first in the Runas specification. When sudo is configured to allow a user to run commands as an arbitrary user via the ALL keyword in a Runas specification, it is possible to run commands as root by specifying the user ID -1 or 4294967295. With targetpw turned off, passing -1 as uid works (even without NOPASSWD) on all our supported distributions.
#Cve 2019 14287 exploit verification#
In this case, the password verification is skipped entirely and the trick with passing -1 as uid will work. Sudotest ALL = (ALL, !root) NOPASSWD: /usr/bin/id The administrator would have to add NOPASSWD to make the bug exploitable, such as Sudo: PAM authentication error: User not known to the underlying authentication module We set the targetpw Defaults option, which means that the user needs to enter the password of the user under whom the command will be run, instead of its own.Īs a consequence of that, the user can't supply a non-existing uid, as it has to exist in the password database for the password check. Our default installation actually limits this even more. The other cases are covered by various sudo checks. The user sudotest will be able to use the uid #-1 trick to launch /usr/bin/whatever as root.
Sudotest ALL = (ALL, !root) NOPASSWD: /usr/bin/whatever Basically the only way to exploit this issue is when sudoers contains entry like
0 kommentar(er)
