[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2192724.2zUfYGIebn@eee>
Date: Sun, 25 May 2014 11:17:52 +0200
From: Raphael Geissert <geissert@...ian.org>
To: cve-assign@...re.org
Cc: oss-security@...ts.openwall.com, Guillem Jover <guillem@...ian.org>
Subject: Re: Re: CVE request: directory traversal in DSA-2915-1-patched dpkg in Debian squeeze
Hi,
Apologies for the late response.
On Thursday 01 May 2014 20:52:37 cve-assign@...re.org wrote:
[...]
> 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.
Debian doesn't have a policy such as the one in the third point. I'm CC'ing
the dpkg maintainer to allow him to answer from his POV.
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
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.
