Re: Re: CVE request: sudo TZ issue

["Todd C. Miller" <Todd.Miller () courtesan com>]

On Wed, 11 Feb 2015 00:59:16 -0500, cve-assign () mitre org wrote:

> We are not sure why this is being interpreted as a vulnerability in
> sudo that should have a CVE assignment in which sudo is the
> responsible product. It appears that you are adding a new security
> feature in which sudo chooses to help prevent exploitation of bugs in
> a system library such as libc. Adding security features is often not
> within the scope of CVE. We're not disputing that it's worthwhile for
> you to change the sudo code and publish an alert explaining why you
> did that. It's just that some types of worthwhile changes can have CVE
> IDs whereas others can't.

Initially, I was also of the opinion that this was a libc issue and
not a sudo one.  However, since TZ can be used to read arbitrary
files it can hijack input from arbitrary ptys and things like
/proc/kmsg it seems like a general problem.

In some ways running a command via sudo is similar to running a
setuid executable, but without the protection of AT_SECURE or
issetugid() checks done by libc (or the executable itself).  As
such, sudo bears some responsibility to sanitize the environment
in a manner similar to what libc would do.

> Depending on how other code is written, a TZ value could still be
> malicious even if it doesn't satisfy the definition of "unsafe" that
> you included. Should there be other CVEs for sudo if any such code is
> identified?

There are really two issues here: exposure of TZ parsing bugs and
access to arbitrary (potentially user-controlled) files.  I'm happy
to put the blame for TZ parsing bugs on libc or the application.
However, there is no real way for the application to tell that it
is being run by an unpriviliged user and that operations that would
otherwise be safe (opening a user-specified time zone file) may be
dangerous.

> To be clear, you can have a CVE assignment if, as the "vendor" of
> sudo, you believe that absense of the new "unsafe" checking was an
> implementation mistake in sudo. However, in that case, can you clarify
> whether it is one mistake or multiple mistakes? For example, is there
> a documented or implied security policy for sudo that addresses the
> current situation? A policy might be something like:
>
>  - for every environment variable passed through by default, there is
>    supposed to be a proactive review of all common use cases of that
>    environment variable, and sudo is supposed to have input validation
>    that ensures that the environment variable's value is normal and
>    properly handled within that use case
>
> or, for multiple policies:
>
>   - sudo is supposed to prevent traversal attacks with environment
>     variables
>   
>   - sudo is supposed to block syntactically invalid values of
>     environment variables
>
>   - sudo is supposed to block long values of environment variables

By default, sudo will run commands with a minimal copy of the
environment that is considered to be "safe".  Defining "safe" is
difficult since there's no way for sudo to know how an application
will use an environment variable.  However, sudo has historically
done some simple filtering of the environment variables in the
"env_check" list to avoid some library and application bugs.

For instance COLORTERM, LANG, LANGUAGE, LC_*, LINGUAS and TERM are
filtered if they contain '%' or '/' characters to avoid potential
printf format vulnerabilities and interpretation as a path respectively.
Filtering TZ is consistent with the promise that commands be started
with a "safe" environment.  I don't think it is unreasonable to
expect sudo to implement the same kind of environment checks that
would be performed by libc for a setuid program.

 - todd