Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ