[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RFC - mark CVE-2017-18641/lxc as <no-dsa> or <ignored>?

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.


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.


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

Your feedback, discussion, suggestions, etc. on this are most welcome.



Roberto C. Sánchez

Reply to: