Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 539532 (CVE-2014-9680) - <app-admin/sudo-1.8.12: Unsafe handling of TZ environment variable (CVE-2014-9680)
Summary: <app-admin/sudo-1.8.12: Unsafe handling of TZ environment variable (CVE-2014-...
Status: RESOLVED FIXED
Alias: CVE-2014-9680
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
URL: http://seclists.org/oss-sec/2015/q1/486
Whiteboard: A3 [glsa]
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-09 22:31 UTC by Kristian Fiskerstrand (RETIRED)
Modified: 2016-03-08 08:23 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kristian Fiskerstrand (RETIRED) gentoo-dev 2015-02-09 22:31:39 UTC
From ${URL}:
I'm going to be releasing sudo 1.8.12 shortly 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.

Credit:

Jakub Wilk began a discussion about abusing the TZ environment
variable on the oss-security mailing list.

Stephane Chazelas also reported the problem and supplied some
concrete examples of how it could be abused.
Comment 1 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2015-03-29 10:59:52 UTC
+ *sudo-1.8.12 (10 Feb 2015)
+
+   10 Feb 2015; Lars Wendler <polynomial-c@gentoo.org> -sudo-1.8.6_p7.ebuild,
+   +sudo-1.8.12.ebuild:
+   Security bump (bug #539532). Removed old.

Guys, dunno why I failed to report this in the bug here but this has been added to the tree over a month ago.


Arches please test and mark stable =app-admin/sudo-1.8.12 with target KEYWORDS:

alpha amd64 arm ~arm64 hppa ia64 ~m68k ~mips ppc ppc64 ~s390 ~sh sparc x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd ~x64-freebsd ~sparc-solaris
Comment 2 Mikle Kolyada (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2015-03-29 11:41:03 UTC
amd64 stable
Comment 3 Agostino Sarubbo gentoo-dev 2015-03-29 12:08:17 UTC
x86 stable
Comment 4 Agostino Sarubbo gentoo-dev 2015-03-30 09:51:06 UTC
sparc stable
Comment 5 Agostino Sarubbo gentoo-dev 2015-03-30 10:07:14 UTC
alpha stable
Comment 6 Jeroen Roovers (RETIRED) gentoo-dev 2015-03-30 15:42:15 UTC
Stable for HPPA.
Comment 7 Agostino Sarubbo gentoo-dev 2015-03-31 07:57:22 UTC
ppc64 stable
Comment 8 Markus Meier gentoo-dev 2015-04-02 19:55:31 UTC
arm stable
Comment 9 GLSAMaker/CVETool Bot gentoo-dev 2015-04-11 14:58:07 UTC
This issue was resolved and addressed in
 GLSA 201504-02 at https://security.gentoo.org/glsa/201504-02
by GLSA coordinator Mikle Kolyada (Zlogene).
Comment 10 Mikle Kolyada (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2015-04-11 15:06:57 UTC
ia64/ppc stable
Comment 11 Yury German Gentoo Infrastructure gentoo-dev 2015-06-06 14:41:35 UTC
Maintainer(s), please drop the vulnerable version(s).
Comment 12 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2015-06-06 16:59:55 UTC
+  06 Jun 2015; Lars Wendler <polynomial-c@gentoo.org> -sudo-1.8.11_p1.ebuild,
+  -sudo-1.8.11_p2.ebuild:
+  Removed vulnerable versions.
+
Comment 13 Aaron Bauman (RETIRED) gentoo-dev 2016-03-08 08:23:06 UTC
Vulnerable versions dropped per previous comments and this was addressed in https://security.gentoo.org/glsa/201504-02