[OSSA 2014-033] GlusterFS driver uses unsafe qcow2 format detection (CVE-2014-3641)

[Eric Harney]

Concern about this was raised by Duncan Thomas.

The GlusterFS Cinder driver uses "qemu-img info" to guess at whether a volume file is a raw image or a qcow2 image.

This is unsafe because if a user writes a qcow2 header into a volume, Cinder will interpret it as a qcow2-formatted image. It is believed this can lead to data being extracted from files on the Cinder volume host by writing a qcow2 header with a backing file pointer referencing a path to a file, and then cloning the volume. (Other similar paths may exist.)

To fix this, Cinder needs to track the file format of any file being processed this way and use "qemu-img convert -f <source_format>" when performing operations like volume clone, which disables qemu-img's auto format detection.

This seems to affect the GlusterFS driver, but it is possible that other attack vectors exist. The convert_image() method in cinder/image/image_utils.py is used in assorted places and does not specify a source format, so other uses of it will need to be examined for safety.

Fixing this in the GlusterFS driver is not simple: since volume/snapshot qcow2 chains are manipulated by Nova as well as Cinder, we will need to have Nova pass information back to Cinder when an operation such as volume_snapshot_delete is performed, indicating the resulting format of any files modified.

Since the above is a large effort, it may be possible to mitigate this in the short-term by having Cinder enforce some rules about whether a backing file pointer is valid before performing an operation on the file. For the GlusterFS driver that would be: must start with 'volume-<x>' and not contain '/', since our valid usage of this only points to another file named volume-<id>.<id> and does not use paths.

This attack hasn't yet been demonstrated to work, but this is a commonly known problem when processing qcow2 files.

[Tristan Cacqueray (tristan-cacqueray)]

Thanks for the report, the advisory task is in an incomplete state pending feedback from the cinder-coresec team.

[Eric Harney (eharney)]

Another way to mitigate this in the short term may be to force volumes to be in qcow2 format. (glusterfs_qcow2_volumes option)

[Duncan Thomas (duncan-thomas)]

Forcing volumes to be qcow2 format always completely removes the issue - migration of old volumes is the issue there.

Validation of the backing chain can't just be by path / regex, as one avenue for attack is to use other tenant's volumes as backing files, which will have the correct path and name structure.

[Eric Harney (eharney)]

We can have backing chain validation insist that files start with the same volume & uuid filename, which should prevent access to anything outside of the correct data.

[Thierry Carrez (ttx)]

@Duncan: my understanding is that you confirm that this is an issue, so we should issue an advisory about this. If not, let us know :)

[Thierry Carrez (ttx)]

@Eric: do you have any patch you could attach to this (private) bug for review ?

[Duncan Thomas (duncan-thomas)]

Yes, I confirm this is an issue, and I do believe we should issue an advisory. Looking forward to seeing a fix.

[Thierry Carrez (ttx)]

Eric said he would look at this in a day or two.

[Eric Harney (eharney)]

This is a WIP patch which, I think, mitigates the security issue here. It disallows any operations on qcow2 files which have unexpected backing file pointers. If the backing file is not the expected format (based to the path the Gluster share is mounted to and the volume id ) then operations such as clone or delete snapshot will not be allowed.

I was able to reproduce this issue by:
 - Create a volume
 - Attach to VM
 - From within the guest, write qcow2 header to the volume pointing to /etc/passwd (arbitrary file) as the backing file
 - Detach volume
 - Clone volume
 - Attach the new volume: data from the host's /etc/passwd is seen.

This patch is likely not complete and not all of the changed paths have been tested, but I wanted to float this as an idea for an interim fix to get some feedback, since the proper fix will take some time. (The patch also still contains two LOG.errors which are just for testing and should be removed, and it needs unit tests.)

Note that this does not prevent a user from corrupting their own data by doing something like writing a qcow2 header that points to a different file in their qcow2 snapshot chain for that volume (which they do have access to). It should disallow data from any other Cinder volume or file on the c-vol host from being leaked.

(Also TODO: test w/ volume migration since it does strange things with changing volume IDs)

[Tristan Cacqueray (tristan-cacqueray)]

Thanks for providing a patch!
I have nominated icehouse and havana series because the affected code is also present in those release.
Can you confirm those versions are also impacted ?

[Duncan Thomas (duncan-thomas)]

I think the full fix needs to do more than the attached draft path, since that seems to still allow me to access other tenant's volumes if I know the uuid of the volume (I'm only looking at the code, I haven't proven it)

[Tristan Cacqueray (tristan-cacqueray)]

Here is impact description draft #1:

Title: Compute host data leak to vm instance with Cinder volume
Reporter: Duncan Thomas (HP)
Products: Cinder
Versions: up to 2013.2.3 and 2014.1 versions up to 2014.1.2

Description:
Duncan Thomas from Hewlett Packard reported a vulnerability in Cinder GlusterFS driver. By overwriting a volume from within an instance with a malicious qcow2 header, an authenticated user may be able to clone and attach that corrupted volume resulting in Cinder leaking an arbitrary file from the compute host to the virtual instance. Note that the host file must be readable by the libvirt/kvm context to be exposed. Only Cinder setups using GlusterFS volume driver are affected.

Some questions:
Does the malicious volume allow write operation as well ?
Is the leaked through libvirt/kvm context ?
Should Eric Harney be added to the reporter list ?

[Eric Harney (eharney)]

Duncan: It's checking based on the UUID of the volume being operated on, so I don't believe that is possible?

[Tristan Cacqueray (tristan-cacqueray)]

From the VMT point of view, UUID guessing based attacks are not considered a practical vulnerability...

[Eric Harney (eharney)]

Comments on Tristan's description:

I was focusing on Cinder-volume host data leak rather than compute host -- I'm not sure if a compute host leak is possible yet, but it might be. (Write the bad header, detach, reattach it w/o any other operations? I'll need to test this.)

The description paragraph there would result in leaking a file on the cinder-volume host, not the compute host.

We also need to note as a workaround that setting glusterfs_qcow2_volumes=True in cinder.conf prevents this issue for any volumes created after that option is set. (This is False by default.)

> Does the malicious volume allow write operation as well ?
I can't currently come up with a way that it would. This would be possible if you could inject a bad qcow2 header into a snapshot file, but since it's only possible for the base volume file, I can't think of any sequence of events that would allow this.

We only do two types of writes based on qcow2 backing file headers:
 1) commits of snapshot files down to the base volume file or another snapshot file
 2) pulls of base volume files up into a snapshot file.

> Is the leaked through libvirt/kvm context ?
Need to look at the above scenario about compute host leaks and get more info on this point.
The one I described was in the cinder-volume context, which in most deployments is running as a "cinder" user.

> Should Eric Harney be added to the reporter list ?
Probably not, Duncan pointed this out to me elsewhere, I just filed the bug to get things moving.

> From the VMT point of view, UUID guessing based attacks are not considered a practical vulnerability...
I don't think that even successful UUID guessing would buy you anything with the proposed patch. It restricts data access to the volume identified by the UUID which you already know and already have access to.

[Tristan Cacqueray (tristan-cacqueray)]

Thanks for the additional details!

Here is impact description draft #2:

Title: Cinder-volume host data leak to vm instance
Reporter: Duncan Thomas (HP)
Products: Cinder
Versions: up to 2013.2.3 and 2014.1 versions up to 2014.1.2

Description:
Duncan Thomas from Hewlett Packard reported a vulnerability in Cinder GlusterFS driver. By overwriting a volume from within an instance with a malicious qcow2 header, an authenticated user may be able to clone and attach that corrupted volume resulting in GlusterFS driver leaking an arbitrary file from the Cinder-volume host to the virtual instance. Note that the host file must be readable by the Cinder context to be exposed. Only Cinder setups using GlusterFS volume driver configured with glusterfs_qcow2_volumes=False (which is the default) are affected.

[Thierry Carrez (ttx)]

Impact desc looks good!

[Tristan Cacqueray (tristan-cacqueray)]

The master patch apply cleanly on stable/icehouse, though run_tests.sh produced errors, like:
 cinder.tests.test_glusterfs.GlusterFsDriverTestCase.test_backup_snap_failure_2
 cinder.tests.test_glusterfs.GlusterFsDriverTestCase.test_backup_volume

-> AttributeError: No values given for arguments: volume_id

And the patch does not apply on stable/havana...

@glance-coresec/@eric: if the master patch looks good to you, any chance you also provide backports for stables in order for VMT to proceed to CVE request ?

[Eric Harney (eharney)]

This patch needs more work. It fails snapshot-delete operations on a migrated GlusterFS volume because it only checks id and not name_id.

[Eric Harney (eharney)]

Updated fix for this issue to address the migrated volume problem.

[Eric Harney (eharney)]

Note that the pending "SMBFS volume driver" [1] uses similar snapshot functionality and may have a similar problem. It may also conflict w/ this fix.

[1] https://review.openstack.org/#/c/106046/

[Tristan Cacqueray (tristan-cacqueray)]

@Cinder-coresec can someone please have a look at eric proposed patch #20 ?

It seems there is a minor conflict on master when trying to apply it...

[Jay Bryant (jsbryant)]

Looking through Eric's proposed patch it seems reasonable to me.

[Eric Harney (eharney)]

Update to current master (52cc2f) and protect the smbfs driver as well.

The smbfs driver is currently not vulnerable in the default configuration (using qcow2 by default to avoid this), but raw format can be enabled, which exposes this issue.

I don't have a configuration to test the smbfs changes.

[John Griffith (john-griffith)]

+1 on the add in comment #24

[Duncan Thomas (duncan-thomas)]

Looks like there's a merge problem with the patchset in #24, Eric is looking into it

[Eric Harney (eharney)]

Revised patch (against master 69b4cfd).

Previous patch would break the smbfs driver because it used the wrong config option.

[Duncan Thomas (duncan-thomas)]

#27 looks right to me. +2

[Tristan Cacqueray (tristan-cacqueray)]

Thanks Eric!

The master patch is looking good, tests passed successfully.
Can you please submit backports for Icehouse and Havana too ?

[Eric Harney (eharney)]

One-liner update since the wrong exception was being raised from the RemoteFS code.

[Lucian Petrut (petrutlucian94)]

Can you please change this in the Windows SMB driver as well? The only thing that needs to be done is updating the _qemu_img_info method, adding the volume_name parameter defaulting to None, so that this patch won't break it.

https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/windows/smbfs.py#L138

The idea is that this driver does not use qemu-img actually (among others, it can not open in-use images on Windows, so it's using the Win32 API instead ATM) so the method is there for consistency.

Note that for the moment, only vhd/vhdx images are supported by this driver, so it is not exposed to the above mentioned security issue.

[Tristan Cacqueray (tristan-cacqueray)]

@cinder-coresec Should I add in the impact description:
  "Cinder setups using Smbsf with raw format enabled (not default) is also affected" ?

Comment #24 says smbfs is affected, but comment #31 suggest it is not...

[Lucian Petrut (petrutlucian94)]

@Tristan Cacqueray Actually, there are two smbfs drivers. The one supposed to run on Windows is the one that's not affected by the bug, but will be affected by the fix. Without the change I've mentioned above (which is just about one LOC), the driver will be broken.

[Tristan Cacqueray (tristan-cacqueray)]

@Neutron-coresec : can you please review the patch submitted in #30. It still applies and pass unit-tests here.

We also need a stable/icehouse backport to progress on this bug (note that stable/havana is not necessary anymore). Some adjustments need to be done for smbfs.

Note that stable/havana is not required anymore as it reached EOL.

[Duncan Thomas (duncan-thomas)]

I think you meant @cinder-coresec there.

The fix in #30 looks good from a security point of view.

I think Petrut is correct in requiring his patch to be applied too to stop the windows driver being broken, though I can't test it.

The linux smb driver is affected, but is fixed by Eric's patch.

[John Griffith (john-griffith)]

Sorry I let this sit so long. First glance it looks good, but I'd like to spend some time later today looking more closely. I'll update in a few hours.

[Tristan Cacqueray (tristan-cacqueray)]

@Duncan oups, cinder-coresec indeed :)

Thank you for the review and the clarification on smbfs driver!
Here is the updated impact description:

Title: Cinder-volume host data leak to vm instance
Reporter: Duncan Thomas (HP)
Products: Cinder
Versions: up to 2014.1.2

Description:
Duncan Thomas from Hewlett Packard reported a vulnerability in Cinder GlusterFS and Linux Smbfs driver. By overwriting a volume from within an instance with a malicious qcow2 header, an authenticated user may be able to clone and attach that corrupted volume resulting in affected drivers leaking an arbitrary file from the Cinder-volume host to the virtual instance. Note that the host file must be readable by the Cinder context to be exposed. Only Cinder setups using GlusterFS volume driver configured with glusterfs_qcow2_volumes=False (which is the default) or Cinder setups using Smbfs volume driver configured with smbfs_default_volume_format=raw (which is not the default) are affected.

[Jeremy Stanley (fungi)]

Tristan's updated impact description in comment #37 looks good.

[John Griffith (john-griffith)]

Tristans description as well as Eric's patch LGTM, +1 on both

[Tristan Cacqueray (tristan-cacqueray)]

Icehouse patch in comment #40 is looking good to me, beside these pep8 errors:
cinder/volume/drivers/glusterfs.py:177:5: E303 too many blank lines (2)
cinder/volume/drivers/glusterfs.py:636:80: E501 line too long (80 > 79 characters)
cinder/volume/drivers/glusterfs.py:658:80: E501 line too long (80 > 79 characters)
cinder/volume/drivers/glusterfs.py:755:80: E501 line too long (85 > 79 characters)

Can a cinder-coresec please approve this backport ? We can eventually hope for a disclosure date next week.

[Eric Harney (eharney)]

Oops, fix pep8 issues for icehouse patch.

[Jay Bryant (jsbryant)]

I am ok with this as a stop-gap solution and Eric's code looks good to me.

[Thierry Carrez (ttx)]

Let's not tie it to the RC process, but try to include it in final

[John Griffith (john-griffith)]

@Thierry
I have no objection to that, however I would like to land it ASAP and then figure out if we need to make changes to the Windows SMB driver as a result before final release. Honestly today vs Monday doesn't matter we can certainly take our chances but I just don't want it to sit much longer if we can help it.

[Thierry Carrez (ttx)]

Sure, definitely land it in RC1 if you can ! The issue being, this issue being embargoed we'll need to give some advance notice, so RC1 would be artificially delayed by ~ 5 days... so I'd prefer we don't block on it.

[Thierry Carrez (ttx)]

I think this is ready for pre-OSSA

[Tristan Cacqueray (tristan-cacqueray)]

The advance notification (pre-OSSA) have been sent with a disclosure date set to:
2014-10-02, 1500UTC

[Lucian Petrut (petrutlucian94)]

I've attached the one liner patch that needs to be applied so that the previous patch does not break the Windows SMBFS driver.

I've tested the SMBFS drivers with the 2 patches applied having no issues.

[Tristan Cacqueray (tristan-cacqueray)]

@cinder-coresec: can you please review that very last fix ? Unit tests are running fine with and without it...

[Tristan Cacqueray (tristan-cacqueray)]

Can someone confirm "Windows-SMBFS-Handle-volume_name-in-_qemu_img_info.patch" is really effective ?

Applied on master after "Refuse-invalid-qcow2-backing-files-rev3_master_69b4cfd.patch" it only adds "volume_name=None" parameter to _qemu_img_info() that seems unused (either by caller or in the function body)...

[Eric Harney (eharney)]

Tristan:
That patch isn't part of the security fix proper. It is something we should land after the security patch goes in to prevent the Windows driver from breaking. It should be considered separate from this bug at this point.

(Note: I've looked at this issue a bit previously but haven't analyzed Petrut's patch in detail.)

[Lucian Petrut (petrutlucian94)]

@Tristan:

Here's a trace, showing up why that is required:
http://paste.openstack.org/show/117171/

The idea is that the methods from the base class will now pass one extra argument, namely volume_name, and even if that method ignores it (because of the reasons I've mentioned earlier), it must accept it, otherwise that will raise the exception from the above trace.

As I've said, it's just a one liner but keeps the driver from breaking after this security fix is applied.

[Tristan Cacqueray (tristan-cacqueray)]

Thanks for the clarification. I'm amending this last fix to the pre-OSSA as stakeholder might be impacted by this error after applying the security patch.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/125665

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/125666

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/icehouse
Review: https://review.openstack.org/125667

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: proposed/juno
Review: https://review.openstack.org/125671

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: proposed/juno
Review: https://review.openstack.org/125672

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/icehouse
Review: https://review.openstack.org/125710

[OpenStack Infra (hudson-openstack)]

Change abandoned by Eric Harney (<email address hidden>) on branch: stable/icehouse
Review: https://review.openstack.org/125667
Reason: Moved to https://review.openstack.org/#/c/125710/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/125665
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=dca3c8323cf8cf12aa8ce4ba21f647ce631e8153
Submitter: Jenkins
Branch: master

commit dca3c8323cf8cf12aa8ce4ba21f647ce631e8153
Author: Eric Harney <email address hidden>
Date: Tue Sep 9 16:20:24 2014 -0400

    Refuse invalid qcow2 backing files

    Don't allow qcow2 files that are pointing to backing files outside of:

    volume-<id>
    volume-<id>.<snap-id>
    volume-<id>.tmp-snap-<snap-id>

    (optionally prefixed with /mnt/path)

    Closes-Bug: #1350504

    Change-Id: Ic89cffc93940b7b119cfcde3362f304c9f2875df

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/125710
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=7eef59602206b529d7acdcbe8055d0d0d63d0d85
Submitter: Jenkins
Branch: stable/icehouse

commit 7eef59602206b529d7acdcbe8055d0d0d63d0d85
Author: Eric Harney <email address hidden>
Date: Wed Sep 24 15:13:15 2014 -0400

    Refuse invalid qcow2 backing files

    Don't allow qcow2 files that are pointing to backing files outside of:

    volume-<id>
    volume-<id>.<snap-id>
    volume-<id>.tmp-snap-<snap-id>

    (optionally prefixed with /mnt/path)

    Closes-Bug: #1350504

    Change-Id: Ic89cffc93940b7b119cfcde3362f304c9f2875df

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/125666
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=5e0ce63d6df39dcad5a0ef35553369e49c67dfb8
Submitter: Jenkins
Branch: master

commit 5e0ce63d6df39dcad5a0ef35553369e49c67dfb8
Author: Lucian Petrut <email address hidden>
Date: Tue Sep 30 11:58:22 2014 +0300

    Windows SMBFS: Handle volume_name in _qemu_img_info

    The volume_name is now parsed to the _qemu_img_info wrapper. As
    this method is not prone to security issues because this driver
    does not support raw images (at least not yet), we don't have to
    perform any checks on the backing image file path.

    Thus, this method simply ignores this argument that will be parsed
    by the base class methods.

    Related-Bug: #1350504

    Change-Id: I801a6338250ec2dc631c4058543f7d0088b3e4d4

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/125671
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=608ecf565f99b9840095ecff424e396c4bae631a
Submitter: Jenkins
Branch: proposed/juno

commit 608ecf565f99b9840095ecff424e396c4bae631a
Author: Eric Harney <email address hidden>
Date: Tue Sep 9 16:20:24 2014 -0400

    Refuse invalid qcow2 backing files

    Don't allow qcow2 files that are pointing to backing files outside of:

    volume-<id>
    volume-<id>.<snap-id>
    volume-<id>.tmp-snap-<snap-id>

    (optionally prefixed with /mnt/path)

    Closes-Bug: #1350504

    Change-Id: Ic89cffc93940b7b119cfcde3362f304c9f2875df
    (cherry picked from commit dca3c8323cf8cf12aa8ce4ba21f647ce631e8153)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/125672
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=79afa849658f689a9105473fdfba1d993684d3df
Submitter: Jenkins
Branch: proposed/juno

commit 79afa849658f689a9105473fdfba1d993684d3df
Author: Lucian Petrut <email address hidden>
Date: Tue Sep 30 11:58:22 2014 +0300

    Windows SMBFS: Handle volume_name in _qemu_img_info

    The volume_name is now parsed to the _qemu_img_info wrapper. As
    this method is not prone to security issues because this driver
    does not support raw images (at least not yet), we don't have to
    perform any checks on the backing image file path.

    Thus, this method simply ignores this argument that will be parsed
    by the base class methods.

    Related-Bug: #1350504

    Change-Id: I801a6338250ec2dc631c4058543f7d0088b3e4d4
    (cherry picked from commit 5e0ce63d6df39dcad5a0ef35553369e49c67dfb8)

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/128920

[Rohit Maheshwari (maheshwarirohit87)]

I am trying to install openstack Ice house but i am not able to do that.Can you please give me step by step to install it on my laptop on my vmware

[OpenStack Infra (hudson-openstack)]

Change abandoned by Mike Perez (<email address hidden>) on branch: master
Review: https://review.openstack.org/128920

[Deepak C Shetty (dpkshetty)]

@Eric, @Duncan,
   Using qemu-img check <qcow2-file> might help here ?
I am hoping that qemu-img check should catch and fail the consistency check if the file was tampered with ?

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/128920
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=66494f54112fdfa135b3974c75aa388c8d1fb49e
Submitter: Jenkins
Branch: master

commit be3d4604dc0566e0838959d998ff1d37755de6d3
Author: Tomoki Sekiyama <email address hidden>
Date: Tue Oct 14 19:09:44 2014 -0400

    Fix LVM iSCSI driver tgtadm CHAP authentication

    Currently CHAP Authentication in LVM iSCSI driver with tgtadm does not work.
    This is because the tgtadm helper creates the target configuration file
    with an 'IncomingUser' entry, which is ignored by tgtd.
    This patch fixes it to 'incominguser'.

    Change-Id: I14871985a2a916834122f849238f05b75726bc1a
    Closes-Bug: #1329214
    (cherry picked from commit e3563891545c801726d227f752cf99488ed5c7dd)

commit f7ee62cc58d8b642af67510a310f6259492a4508
Author: Mitsuhiro Tanino <email address hidden>
Date: Tue Oct 14 12:41:41 2014 -0400

    Export cinder volumes only if the status is 'in-use'

    Currently, cinder volumes are exported both 'in-use' and 'available'
    after restarting cinder-volume service.
    This behavior was introduced following commit.

      commit ffefe18334a9456250e1b6ff88b7b47fb366f374
      Author: Zhiteng Huang <email address hidden>
      Date: Sat Aug 23 18:32:57 2014 +0000

    If the volumes are attached to nova instances, they should be exported
    via tgtd after restarting cinder-volume.
    But the volumes which are not attached to instances must not be exported
    because everyone can connect these volumes.

    This patch changes volume export behavior that exports a volume only if
    the volume status is 'in-use'.

    Change-Id: I4c598c240b9290c81bd8001e5a0720c8c329aeb9
    Signed-off-by: Mitsuhiro Tanino <email address hidden>
    Closes-bug: #1381106
    (cherry picked from commit e2f28b967910625432be0eab6a851adf53ac58ea)

commit 01e7c516852e53df661b2eedc970c327c1ff10ce
Author: Vipin Balachandran <email address hidden>
Date: Fri Oct 10 23:06:27 2014 +0530

    Revert "Relocate volume to compliant datastore"

    Commit 4be8913520f5e9fe4109ade101da9509e4a83360 introduced a regression
    which causes failures during cinder volume re-attach. This patch reverts
    commit 4be8913520f5e9fe4109ade101da9509e4a83360 as an immediate fix.

    Closes-Bug: #1379830
    Change-Id: I5dfbd45533489c3c81db8d256bbfd2f85614a357
    (cherry picked from commit 48cb82971e0418f9a629e2b39d0433dc2c0e6919)

commit 900d49723f65e87658381ff955559f54ac98c487
Author: Andreas Jaeger <email address hidden>
Date: Thu Oct 9 12:25:28 2014 +0200

    Updated translations

    Commands run:-
    $ python setup.py extract_messages
    $ python setup.py update_catalog --no-fuzzy-matching \
      --ignore-obsolete=true
    $ source \
      ../openstack-infra/project-config/jenkins/scripts/common_translation_update.sh
    $ setup_loglevel_vars
    $ cleanup_po_files cinder

    Change-Id: I73f3bdccb4be98df95fa853864e465f4d83a8884

commit 8e94aaa2b28b491314fe8642061ac73e3fe8e966
Author: Navneet Singh <email address hidden>
Date: Thu Aug 28 16:03:41 2014 +0530

    NetApp fix eseries unit test mock clean

 ...