oss-security - Re: CVE request: sudo TZ issue

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20150211055916.4B62342E0D3@smtpvbsrv1.mitre.org>
Date: Wed, 11 Feb 2015 00:59:16 -0500 (EST)
From: cve-assign@...re.org
To: Todd.Miller@...rtesan.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE request: sudo TZ issue

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> http://www.sudo.ws/alerts/tz.html

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.

For example, see:

  http://www.openwall.com/lists/oss-security/2014/10/16/2

Also:

> As such, a program run via sudo will inherit the (possibly malicious)
> value of TZ.

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?

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

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)

iQEcBAEBAgAGBQJU2u8mAAoJEKllVAevmvmswp8H/0HzL1216WeNJxPvb3E5SSOf
nZv/2M5BxOdC4OTWmVPzxmUVkwKlTMlf7iKLOZqb2scsrRGHi8EshsSvLZ2iFKIy
Y+axIv8YqS8IkvAC3rgDegY8DYrN4+phffHfzAa9ekrndgIjFEjk9AFo4u7p0xUs
rBtohfkufg0wWpajUctfkeV8MnoA4RSpZDu1MymNdfdx4c66Wyu28LFY8/scqscO
UO1/RcpwRXp1rJS5SBsa+HsW+TohROzMHMhWTphStHWb3fNMhm9+X6hYQydbeFWh
EjK0TlhwXT3Vm6eoPQBaPdheKDU8F+YvhUDtxKeQzmhrjuVpy56YDV/uXQWHtBU=
=I0i/
-----END PGP SIGNATURE-----

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.