[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201405020052.s420qbH8009487@linus.mitre.org>
Date: Thu, 1 May 2014 20:52:37 -0400 (EDT)
From: cve-assign@...re.org
To: geissert@...ian.org
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE request: directory traversal in DSA-2915-1-patched dpkg in Debian squeeze
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> The recent update of dpkg for CVE-2014-0471 in Debian squeeze actually
> introduces a vulnerability in that release
This is a somewhat unusual situation from the perspective of CVE
assignment. The outcome of 746306 is that C-style filenames aren't
accepted. However, we probably can't assign a CVE ID for a root cause
of "attempts to support C-style filenames," because supporting those
filenames isn't inherently unsafe if an OS vendor is programmatically,
or by policy, ensuring that the patch program is one that interacts
safely with that support.
The
updated dpkg in squeeze + patch(1) from squeeze = vulnerable
behavior is something that seems to be best categorized as a release
engineering problem. Although there are very few cases in which CVE
IDs have been assigned for release engineering problems, these
problems can be within the scope of CVE, and the current one is. Use
CVE-2014-3127 for this issue. In other words, because squeeze's new
dpkg program is incompatible, in a security-relevant way, with
squeeze's patch program, the two should not have been allowed to exist
together within any correctly maintained/supported squeeze
environment.
However, there is another question that could possibly result in a
second CVE ID. On wheezy, there's apparently a security problem in, at
least, these two cases:
1. the installed patch program is an older version of patch that's
identical to squeeze's supported version of patch. Possibly, this
can happen on a correctly maintained/supported Debian system
because sometimes a system is in a partially upgraded state. In
particular, the vulnerability affects root's use of dpkg, which
may be a completely expected activity because the administrator
might want to unpack a source package even though an upgrade is
unfinished.
2. the patch program in root's path is not something obtained from
Debian, e.g., the administrator intentionally decided to install
a non-GNU patch program
We're not sure what can be done about case 1. The general issue is
that, when doing an upgrade of an arbitrary OS, the system might
intermittently be in a state in which incompatibility of
old-OS-version programs and new-OS-version programs has a major
security risk. Maybe the right answer is a policy that nobody is
allowed to do anything while an upgrade is in progress. In other
words, regular users may not be logged in, and root should only be
running the upgrade program and nothing else. ("nothing else" is
impractical; realistically, risk is reduced by running as little else
as possible.)
Case 2 possibly violates the expectations of the concept of a Linux
distribution OS or other OS. In other words, the dpkg program requires
the patch program, and therefore the administrator must ensure that
the patch program (at least, in root's path) is the one provided by
the OS vendor. If the administrator decided to install any other patch
program, the resulting security problem would typically be considered
a site-specific problem and thus outside the scope of CVE. However, a
CVE ID could be assigned of any of these is true:
- on wheezy, dpkg doesn't have any explicit requirements about the
patch program
- the dpkg documentation states that a non-GNU patch program can be
used if desired
- Debian has a general policy that a supported program (such as
dpkg) must be robust in the face of non-standard but reasonable
site-specific software changes. In other words, if Debian program
1 allows arbitrary code execution in situations where the
administrator replaces Debian program 2 with an
often-considered-equivalent non-Debian program, this is supposed
to be treated as a vulnerability in Debian program 1.
- --
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)
iQEcBAEBAgAGBQJTYustAAoJEKllVAevmvmswDgIAIhRUCoIuvrHcrVlhEH2aicu
4eacUenhaY1BfLg167t+csxZooZClRzsykhoun36VlrTT9jzLTBHjrSwupwIaNia
LvdmEEMgRcig0nPIl0233Jew3vIWXD+BJcQXOyyGPmjOmWWUew6JO+hkuDGg2JTr
r3nyNPQafsbdfBWGZ0rnmOqp+gUc+3bgqReVtsogcXvd0yVbKMFdWm1kuOIHeevf
ZWdmBdF2cwWyCGk9SAvRVGj15HxFlmmyuQ4u0PN2oxzbLd8cooJGmZnWz/q8X+h7
A4srxRFTqyHceZgWB0cqsXyjY9oiFEqweC+pA1WHozu+2f2D6isBoH1WYjLOA8c=
=PQIS
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
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.
