Hi Roberto I agree with your analysis.
Best regards // Ola On Wed, 26 Feb 2020 at 16:33, Roberto C. Sánchez <robe...@debian.org> wrote: > Hello all, > > I've been doing some work on CVE-2017-18641/lxc to understand the > precise nature of the vulnerability and potential approaches to fixing > it. It seems not possible to fix the vulnerability, so I'd like to make > a recommendation on how to handle it. > > Recommendation: > > I would like to mark CVE-2017-18641/lxc as <no-dsa> (or <ignored> if > that would be more appropriate). Absent any feedback to the contrary or > alternate suggestions, I will mark the vulnerability as <no-dsa> for > jessie within about a week. > > Summary: > > The LXC templates, as shipped in the jessie version of lxc, > originate from a wide variety of different authors/maintainers, some of > whom deliberately or inadvertently failed to use secure means (e.g., > https, GPG signature validation, hash validation, etc.) for downloaded > components used for container bootstrap. The issue was kept private by > upstream for 3 years, until just recently. The upstream solution was to > provide "distrobuilder" to securely build container base images in a way > which can be supported by the upstream developers. They then deprecated > the old templates as a separate project, lxc-templates. > > Rationale for recommendation: > > There are two elements which led me to the recommendation of <no-dsa> or > <ignored> for this vulnerability. > > First, the upstream solution--deprecate the legacy templates and use > distrobuilder instead--is simply not feasible as part of a security > update. It also seems quite likely that since that architerctural > change was made recently (part of the 3.0.x release series) that making > it work for the 1.0.x release in jessie is not workable. Even if it > were workable, it seems too large a risk for a security update. > > Second, the template scripts for Debian and Debian-based containers > (with the notable exception of CirrOS, a lightweight Ubuntu cloud > variant) all use apt, which provides the same degree of security to > bootstrap a container as is available in a standard Debian installation. > The vulnerable scripts (i.e., those for RedHat, CentOS, Fedora, > OpenMandriva, and related distros) are unlikely to be used to create > containers on a Debian host. What led me to that conclusion was an > examination of the template scripts and a bit of experimentation > creating templates of some of those distros. Each of those scripts > assumes that the necessary package management components (yum, apt-rpm, > zypper, etc.) be installed on the host system. While those components > are available for installation on Debian jessie, it seems somewhat > unlikely that someone interested in creating CentOS, Oracle, or whatever > other distro containers would go to the trouble of installing foreign > package managers to support creation of containers for other (i.e., > non-Debian-ish) distros. > > The second point, to me anyways, significantly reduces the severity of > the vulnerability. That, paired with the infeasibility of implementing > upstream's fix, led me to the above recommendation of <no-dsa> for this > vulnerability. > > Your feedback, discussion, suggestions, etc. on this are most welcome. > > Regards, > > -Roberto > > -- > Roberto C. Sánchez > > -- --- Inguza Technology AB --- MSc in Information Technology ---- | o...@inguza.com o...@debian.org | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | ---------------------------------------------------------------
