[Openstack-devel] Bug#684452: CVE-2012-3447 unblock: nova/2012.1.1-6

[Thomas Goirand]

Hi Adam,

Thanks for your careful review.

On 08/11/2012 04:41 AM, Adam D. Barratt wrote:
> On Fri, 2012-08-10 at 14:25 +0800, Thomas Goirand wrote:
>> Please unblock the nova package. This fixes CVE-2012-3447, which is a
>> file injection vulnerability in the host filesystem, using a specially
>> crafted guest image.
>>
>> The relevant diff is available here:
>> http://anonscm.debian.org/gitweb/?p=openstack/nova.git;a=commitdiff;h=55e78f9cbaa1c4657a97c6b20797a94968030e75
> 
> Please don't do that.  It needs a context switch, doesn't work when
> reading mail offline and means that the list archive doesn't stand alone
> as a historical, well, archive of what was okayed.  There's a reason
> that the freeze policy explicitly asks for debdiffs.

I'm sorry, I wont do it again. I've attached the corresponding diff file
for this unblock request.

>> The patch comes directly from upstream, as per the patch header (I just
>> applied it manually, then did dpkg-source --commit).
>>
>> Note that this also includes a (needed) tweak in the configuration files
>> as per this commit:
>> http://anonscm.debian.org/gitweb/?p=openstack/nova.git;a=commitdiff;h=4cd725c5d164484a3ddb6bf95f37fb715cb51169
> 
> Two questions:
> 
> 1) Why is there no mention of the above changes in the changelog?
> 
> 2) Why does "Add nova-compute.conf files to nova-compute init if exist"
> require
> 
> -DAEMON_ARGS="--flagfile=/etc/nova/nova.conf"
> +DAEMON_ARGS="--config-file=/etc/nova/nova.conf"
> 
> and a bunch of
> 
> +[DEFAULT]
> 
> ?

What happened is that CVE-2012-3447 was embargoed. Ghe Rivero asked me
to take care of it, and upload the patch on the 7th of July, since he
was planing on going in holidays at that time. I'm not sure until when
he is away, he didn't send a mail to -private and I didn't ask him until
when he would go away. Ghe could you send a [VAC] message next time, please?

So I did take care of it, and was expecting to see no change in our Git.
So I did add the upstream patch for this CVE, built, then uploaded to SID.

But I was wrong, as Ghe did this commit, and didn't tell about it. He
didn't fill debian/changelog, which is why I didn't notice it either.

I hate pointing fingers at people, but here, I don't think I'm the one
to blame.

Anyway, let me explain what I believe this patch does. Previously, we
had only a single configuration file, called /etc/nova/nova.conf. But we
changed that, and we are now using /etc/nova/nova-compute.conf also,
which has hypervisor specific flags (for example, nova-compute-kvm will
have libvirt_type=kvm when nova-compute-xen will have
connection_type=xenapi).

So the important bit isn't:
-DAEMON_ARGS="--flagfile=/etc/nova/nova.conf"
+DAEMON_ARGS="--config-file=/etc/nova/nova.conf"

but this:
+test -f '/etc/nova/nova-compute.conf' && DAEMON_ARGS=${DAEMON_ARGS}"
--config-file=/etc/nova/nova-compute.conf"

which is necessary so that our new configuration files are used.

I believe that using --flagfile or --config-file does the exact same
thing. --flagfile was the old option, which has been replaced by
--config-file (and --flagfile is now deprecated). It's a good thing to
do that, so that it matches future releases of Openstack nova.

As for the [default] thing, I don't think that changes much anything,
and to be honest, I'm not really sure why Ghe has added this.
Unfortunately, it's impossible for me to ask him right away now.

Also, it seem to me that it's missing a [default] tag in
debian/nova-compute-xen.conf.dist (that one is only stored in
/usr/share/doc/nova-compute-xen, which is why it has a .dist extension
in the debian folder: /etc/nova/nova-compute.conf is maintained using
debconf in the case of nova-compute-xen). So if that has been forgotten
and is 100% necessary, then we will need to upload a fix and ask for
another unblock later on, I believe.

So, to Ghe, could you, in the future:
1/ Document your changes in debian/changelog *at the same time* as you
commit the rest of in our Git?
2/ Try to limit your changes, since we are frozen, or at least talk
about it in our Alioth list, so that I'm not in an uncomfortable
position like now? Was the addition of the [default] thing completely
necessary?

Anyway, I'm deeply concerned about this CVE. A lot more than these small
changes in the configuration files. I believe it is necessary to
unblock, even if I can't comment as much as I should on the above
changes. Holding the package to enter testing can be harmful to some users.

>> Also, Ubuntu folks already fixed the issue in 12.04.
> 
> How is that at all relevant to the Debian freeze?

This isn't relevant to the freeze, but to the patch for CVE-2012-3447.
I'm just saying that it has been applied in 12.04 and that no user
complained about its accuracy, which is reassuring of the quality of the
patch. Sorry if I didn't make it clear enough.

One last thing: in our Git, I have already a debian/po/es.po update. I
didn't upload the package with it, because of the urgency=high. Was this
the correct thing to do (eg: plan for a later upload then unblock), or
should I have include the template update? Please give me the release
team view on this, so I know how to handle such situation later on.

Also, is it ok to amend the debian/changelog for this release (eg:
2012.1.1-6) on the next upload?

Cheers,

Thomas Goirand (zigo)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nova_2012.1.1-5_to_2012.1.1-6.diff
Type: text/x-diff
Size: 6251 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/openstack-devel/attachments/20120811/427bdff5/attachment.diff>