A flaw was found in sudo before version 1.8.28. 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.
Acknowledgments: Name: the Sudo project Upstream: Joe Vennix (Apple Information Security)
Created attachment 1624516 [details] upstream patch that fixes a test issue
Created attachment 1624734 [details] Upstream fix
Created sudo tracking bugs for this issue: Affects: fedora-all [bug 1761584]
References: https://www.openwall.com/lists/oss-security/2019/10/14/1
External References: https://www.sudo.ws/alerts/minus_1_uid.html
POSSIBLE WORKAROUND: Changing the "ALL" user keyword to a specific user or list of users appears to work around the bug. So, changing ``` %group ALL=(ALL) PRIVCMDS, NOPASSWD: PRIVCMDSNOPW ``` to ``` %group ALL=(root) PRIVCMDS, NOPASSWD: PRIVCMDSNOPW ``` will get ``` $ sudo -u#-1 id -u Sorry, user [USER] is not allowed to execute '/bin/id -u' as #-1 on [FQDN]. ``` (Provided `id` isn't in the list of privileged commands, of course.) I haven't comprehensively tested this workaround, so cases may exist where this doesn't help.
(In reply to David Barr from comment #15) > POSSIBLE WORKAROUND: Changing the "ALL" user keyword to a specific user or > list of users appears to work around the bug. There is no workaround needed for your configuration. > So, changing > > ``` > %group ALL=(ALL) PRIVCMDS, NOPASSWD: PRIVCMDSNOPW > ``` This configuration already allows members of the specified group to run any of the commands defined in PRIVCMDS and PRIVCMDSNOPW as root, without exploiting this flaw. They can just run 'sudo -u root', there's no need to use 'sudo -u#-1'. This flaw does not allow them to run any other command that one of those specified in the configuration. There's nothing to be gained via this flaw in this configuration that is not already permitted. This issue is only relevant for configurations where user is allowed to run some command as any user except of root, i.e. configurations as (ALL, !root). There's no impact for configurations with (ALL), (root), or (some-non-root-user). Affected configurations do not seem to be very common - most sudo uses would be unaffected by this problem.
Affected configurations using (ALL, !root) can be rewritten to explicitly include the list of users the commands can run as. For example use (user1, user2, user3) to specify that commands can be run as one of those 3 users, instead of anyone but root. This may not be usable in cases where the list of target users is long or changing frequently.
Mitigation: This vulnerability only affects configurations of sudo that have a runas user list that includes an exclusion of root. The most simple example is: ~~~ someuser ALL=(ALL, !root) /usr/bin/somecommand ~~~ The exclusion is specified using an excalamation mark (!). In this example, the "root" user is specified by name. The root user may also be identified in other ways, such as by user id: ~~~ someuser ALL=(ALL, !#0) /usr/bin/somecommand ~~~ or by reference to a runas alias: ~~~ Runas_Alias MYGROUP = root, adminuser someuser ALL=(ALL, !MYGROUP) /usr/bin/somecommand ~~~ To ensure your sudoers configuration is not affected by this vulnerability, we recommend examining each sudoers entry that includes the `!` character in the runas specification, to ensure that the root user is not among the exclusions. These can be found in the /etc/sudoers file or files under /etc/sudoers.d.
It does not seem possible to create a simple command to check sudoers configuration if it may or may not be affected. The reason for that is richness of the sudoers configuration language, that makes it possible to exclude user using multiple ways, such as: - user name, i.e. !root - user id, i.e. !#0 - group - name or id, i.e. !%root or !%#0 - defined Runas_Alias Typical configuration do not use all this complexity and should be easy to review for affectedness.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2019:3197 https://access.redhat.com/errata/RHSA-2019:3197
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.5 Extended Update Support Via RHSA-2019:3204 https://access.redhat.com/errata/RHSA-2019:3204
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.6 Extended Update Support Via RHSA-2019:3205 https://access.redhat.com/errata/RHSA-2019:3205
Statement: This flaw only affects specific, non-default configurations of sudo, in which sudoers configuration entry allows a user to run a command as any user except root, for example: someuser myhost = (ALL, !root) /usr/bin/somecommand This configuration allows user "someuser" to run somecommand as any other user except root. However, this flaw also allows someuser to run somecommand as root by specifying the target user using the numeric id of -1. Only the specified command can be run, this flaw does NOT allow user to run other commands that those specified in the sudoers configuration. Any other configurations of sudo (including configurations that allow user to run commands as any user including root and configurations that allow user to run command as a specific other user) are NOT affected by this flaw. Red Hat Virtualization Hypervisor includes an affected version of sudo, however the default configuration is not vulnerable to this flaw.
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-14287
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.4 Advanced Update Support Red Hat Enterprise Linux 7.4 Update Services for SAP Solutions Red Hat Enterprise Linux 7.4 Telco Extended Update Support Via RHSA-2019:3209 https://access.redhat.com/errata/RHSA-2019:3209
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.3 Telco Extended Update Support Red Hat Enterprise Linux 7.3 Advanced Update Support Red Hat Enterprise Linux 7.3 Update Services for SAP Solutions Via RHSA-2019:3219 https://access.redhat.com/errata/RHSA-2019:3219
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.2 Telco Extended Update Support Red Hat Enterprise Linux 7.2 Advanced Update Support Red Hat Enterprise Linux 7.2 Update Services for SAP Solutions Via RHSA-2019:3278 https://access.redhat.com/errata/RHSA-2019:3278
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2019:3694 https://access.redhat.com/errata/RHSA-2019:3694
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.6 Advanced Update Support Via RHSA-2019:3754 https://access.redhat.com/errata/RHSA-2019:3754
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2019:3755 https://access.redhat.com/errata/RHSA-2019:3755
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.5 Advanced Update Support Via RHSA-2019:3895 https://access.redhat.com/errata/RHSA-2019:3895
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.2 Via RHSA-2019:3916 https://access.redhat.com/errata/RHSA-2019:3916
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.1 Via RHSA-2019:3941 https://access.redhat.com/errata/RHSA-2019:3941
This issue has been addressed in the following products: Red Hat Enterprise Linux 5 Extended Lifecycle Support Via RHSA-2019:4191 https://access.redhat.com/errata/RHSA-2019:4191
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.0 Update Services for SAP Solutions Via RHSA-2020:0388 https://access.redhat.com/errata/RHSA-2020:0388