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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ