sudo 1.8.12 will be released shortly [1] which includes sanity checks for the TZ environment variable. This issue was previously discussed here: http://www.openwall.com/lists/oss-security/2014/10/15/24 There is an associated Debian bug: https://bugs.debian.org/772707 From http://www.sudo.ws/alerts/tz.html Summary: Prior to sudo 1.8.12, the TZ environment variable was passed through unchecked. Most libc tzset() implementations support passing an absolute pathname in the time zone to point to an arbitrary, user-controlled file. This may be used to exploit bugs in the C library's TZ parser or open files the user would not otherwise have access to. Arbitrary file access via TZ could also be used in a denial of service attack by reading from a file or fifo that will block. Beginning with sudo 1.8.12, TZ is only passed through by default if it is considered "safe". The TZ variable is now considered "unsafe" if any of the following are true: o It consists of a fully-qualified path name that does not match the location of the zoneinfo directory. o It contains a ".." path element. o It contains white space or non-printable characters. o It is longer than the value of PATH_MAX. Sudo versions affected: Sudo versions prior to 1.8.12 are affected. Details: Unix systems support a user-specified time zone value stored in the TZ environment variable. On many systems, the value of TZ is ignored for set user ID processes (such as sudo) if it does not pass certain sanity checks. However, while the value may be ignored, it is not actually removed from the environment. As such, a program run via sudo will inherit the (possibly malicious) value of TZ. A user with sudo access may take advantage of this to exploit bugs in the C library functions which parse the TZ environment variable. The TZ handling in most C libraries (including GNU libc and the tzcode used by BSD and others) supports reading arbitrary files. By setting TZ to a fully-qualified path name, a command run via sudo may be used to read (but not disclose the contents of) files that the user would not otherwise be able to open. This is generally benign for regular files, but it may be possible to change the behavior of the system by reading from device special files. For instance, it may be possible to hijack the output from a terminal device file, consume kernel log messages or cause a tape drive to change position. It may also be possible to cause a command run by sudo to hang if TZ is set to the value of a named pipe or a device special file that blocks on read. Impact: A user with sudo access may be able to exploit parsing bugs in the time zone parsing functions of the system's C library functions. The user may also be able to read arbitrary files, potentially causing changes in system behavior when reading certain device special files or simply causing the program run via sudo to block. Fix: The bug is fixed in sudo 1.8.12. [1]: http://seclists.org/oss-sec/2015/q1/486
Created sudo tracking bugs for this issue: Affects: fedora-all [bug 1191145]
According to the upstream: Affected sudo versions are 1.0.0 through 1.7.10p9 and 1.8.0 through 1.8.11p2. Sudo 1.8.12 and above are not affected.
sudo-1.8.12-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
sudo-1.8.12-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
External References: http://www.sudo.ws/alerts/tz.html
Related upstream commits: https://www.sudo.ws/repos/sudo/rev/650ac6938b59 https://www.sudo.ws/repos/sudo/rev/91859f613b88 https://www.sudo.ws/repos/sudo/rev/579b02f0dbe0
This issue may only be relevant in configurations where: - users are only allowed to run specific commands via sudo, but are not given full shell access as the target user (i.e. is it not relevant where sudo is only used by system administrators to open shell with root privileges after initially logging in using their non-root accounts) - sudo preserves TZ environment variable setting for commands it run - i.e. when it is configured to not reset environment by default (using env_reset), or is configured to keep TZ value even after environment reset (using env_keep) This issue does not affect the default sudo configuration in Red Hat Enterprise Linux 5, 6, and 7. The default configuration performs environment reset and does not keep TZ value. Starting with sudo upstream version 1.6.9, environment handling was changed to reset environment by default: http://www.sudo.ws/repos/sudo/file/dba251655c76/UPGRADE The env_reset was made the default in Fedora even earlier, in response to flaws as CVE-2004-1051, CVE-2005-4158, and CVE-2006-0151: https://lists.fedoraproject.org/pipermail/devel/2006-February/080598.html https://pkgs.fedoraproject.org/cgit/rpms/sudo.git/commit/?id=c5558ce This Fedora change was inherited by Red Hat Enterprise Linux 5 and later. Until upstream versions 1.8.12 and 1.7.10p9, sudo included TZ variable in the env_keep list by default. However, the sudoers configuration in Red Hat Enterprise Linux 5 and later, and Fedora overrides that compiled-in upstream default by not including TZ in env_keep. Hence the default configuration is not affected by this issue. In affected configurations, this issue can be mitigated by ensuring that TZ environment setting is not preserved for commands executed by sudo. In configurations that use env_reset but do not excluded TZ from env_keep (e.g. when env_keep is not used in sudoers at all and compiled-in default list including TZ is used), TZ can be removed from env_keep using sudoers directive: Defaults env_keep -= "TZ" In configurations that do not use env_reset (such as the default configuration in Red Hat Enterprise Linux 4), sudo can be configured to explicitly remote TZ from environment using sudoers directive: Defaults env_delete += "TZ" Where sudo is used to run specific commands without giving full shell access, it it recommended to use env_reset with a carefully selected list of variables to preserve rather than explicitly configure blacklist of variables to unset.
Statement: This issue did not affect the default sudo configuration in Red Hat Enterprise Linux 5, 6, and 7.
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2015:1409 https://rhn.redhat.com/errata/RHSA-2015-1409.html
This issue was fixed in Red Hat Enterprise Linux 7 via RHBA-2015:2424: https://rhn.redhat.com/errata/RHBA-2015-2424.html Released as part of Red Hat Enterprise Linux 7.2.