sudo-1.8.28 (CVE-2019-14287)

[Douglas R. Reno]

New point version

Contains a critical security fix:

Sudo 1.8.28 has been today, October 14th, 2019 which includes a fix
for the following security-related issue which has been assigned
CVE-2019-14287.  The information below is also available at
https://www.sudo.ws/alerts/minus_1_uid.html

Potential bypass of Runas user restrictions

Summary:
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.

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.

Log entries for commands run this way will list the target user as
4294967295 instead of root.  In addition, PAM session modules will
not be run for the command.

Sudo versions affected:
Sudo versions prior to 1.8.28 are affected.

CVE ID:
This vulnerability has been assigned CVE-2019-14287 in the Common
Vulnerabilities and Exposures database.

Details:
Exploiting the bug requires that the user have sudo privileges that
allow them to run commands with an arbitrary user ID.  Typically,
this means that the user's sudoers entry has the special value ALL
in the Runas specifier.

Sudo supports running a command with a user-specified user name or
user ID, if permitted by the sudoers policy.  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.

    myhost alice = (ALL) /usr/bin/id

Not only is user "alice" 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:

    sudo -u#1234 id -u

would return 1234.

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.  As a result,

    sudo -u#-1 id -u

or
    sudo -u#4294967295 id -u

will actually return 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.

This results in sudo log entries that report the command as being
run by user ID 4294967295 and not root (or user ID 0).  Additionally,
because the user ID specified via the -u option does not exist in
the password database, no PAM session modules will be run.

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.
For example, given the following sudoers entry:

    myhost bob = (ALL, !root) /usr/bin/vi

User bob is allowed to run vi as any user but root.  However, due
to the bug, bob is actually able to run vi as root by running "sudo
-u#-1 vi", violating the security policy.

Only sudoers entries where the ALL keyword is present in the Runas
specifier are affected.  For example, the following sudoers entry
is unaffected:

    myhost alice = /usr/bin/id

In this example, alice is only allowed to run the id command as root.
Any attempt to run the command as a different user will be denied.

Fix:
The bug is fixed in sudo 1.8.28.

Credit:
Joe Vennix from Apple Information Security found and analyzed the
bug.

Patches:
See attached patch for sudo 1.8.27.

[Douglas R. Reno]

 Major changes between version 1.8.28 and 1.8.27:

    Sudo will now only set PAM_TTY to the empty string when no terminal is present on Solaris and Linux. This workaround is only needed on those systems which may have PAM modules that misbehave when PAM_TTY is not set.

    The mailerflags sudoers option now has a default value even if sendmail support was disabled at configure time. Fixes a crash when the mailerpath sudoers option is set but mailerflags is not. Bug #878.

    Sudo will now filter out last login messages on HP-UX unless it a shell is being run via sudo -s or sudo -i. Otherwise, when trusted mode is enabled, these messages will be displayed for each command.

    On AIX, when the user's password has expired and PAM is not in use, sudo will now allow the user to change their password. Bug #883.

    Sudo has a new -B command line option that will ring the terminal bell when prompting for a password.

    Sudo no longer refuses to prompt for a password when it cannot determine the user's terminal as long as it can open /dev/tty. This allows sudo to function on systems where /proc is unavailable, such as when running in a chroot environment.

    The env_editor sudoers flag is now on by default. This makes source builds more consistent with the packages generated by sudo's mkpkg script.

    Sudo no longer ships with pre-formatted copies of the manual pages. These were included for systems like IRIX that don't ship with an nroff utility. There are now multiple Open Source nroff replacements so this should no longer be an issue.

    Fixed a bad interaction with configure's --prefix and --disable-shared options. Bug #886.

    More verbose error message when a password is required and no terminal is present. Bug #828.

    Command tags, such as NOPASSWD, are honored when a user tries to run a command that is allowed by sudoers but which does not actually exist on the file system. Bug #888.

    Asturian translation for sudoers from translationproject.org.

    I/O log timing files now store signal suspend and resume information in the form of a signal name instead of a number.

    Fixed a bug introduced in 1.8.24 that prevented sudo from honoring the value of ipa_hostname from sssd.conf, if specified, when matching the host name.

    Fixed a bug introduced in 1.8.21 that prevented the core dump resource limit set in the pam_limits module from taking effect. Bug #894.

    Fixed parsing of double-quoted Defaults group and netgroup bindings.

    The user ID is now used when matching sudoUser attributes in LDAP. Previously, the user name, group name and group IDs were used when matching but not the user ID.

    Sudo now writes PAM messages to the user's terminal, if available, instead of the standard output or standard error. This prevents PAM output from being intermixed with that of the command when output is sent to a file or pipe. Bug #895.

    Sudoedit now honors the umask and umask_override settings in sudoers. Previously, the user's umask was used as-is.

    Fixed a bug where the terminal's file context was not restored when using SELinux RBAC. Bug #898.

    Fixed a security issue where a sudo user may be able to run a command as root when the Runas specification explicitly disallows root access as long as the ALL keyword is listed first. This vulnerability has been assigned CVE-2019-14287 

[Douglas R. Reno]

Fixed at r22256

Errata added at r1502 in the HTML repo