Activity log for bug #1592163

Date Who What changed Old value New value Message
2016-06-13 21:08:08 Jay Faulkner bug added bug
2016-06-13 21:09:45 Jay Faulkner description The systemd shipped in the upstream, published IPA CoreOS image contains enabled support for automounting GPT partitions marked with the proper GUID (https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html). This automount is triggered by udev anytime GPT partitions are detected. This means that: 1) When deploying images with GPT partitions labelled correctly, they can be immediately mounted into an agent. 2) When cleaning a machine which had properly labelled GPT partitions on disk, these partitions will be mounted on boot, before cleaning begins. This gives the potential for Remote Code Execution in the IPA ramdisk, as a user could craft a filesystem to be mounted in the paths systemd looks for units in, and have those units run. In fact, in some situations, this could lead to existing or newly created units (such as the IPA unit itself) being overridden. To fix this, we'll have to modify the CoreOS image during build to disable this autogenerator. This can be done in the current supported version of CoreOS by `chmod 000 /lib64/systemd/system-generators/systemd-gpt-auto-generator` during the image build process. When the CoreOS image is upgraded to a newer version, we should utilize the masking behavior: https://cgit.freedesktop.org/systemd/systemd/commit/?id=e801700e9a to disable the autogenerator as well. (This is not supported in systemd 212, the version currently shipped by IPA). Additionally, there is a functionality bug as well; when this udev event triggers, it causes a remount event which causes all mounts to remount, including those to support the IPA chroot. This would cause cleaning or deploys to fail in these cases. However, as noted above, this does not mitigate the vulnerability in chroot'd IPA ramdisks as the entire set of units used to spawn IPA could be overridden by a well-crafted partition table + filesystem. The systemd shipped in the upstream, published IPA CoreOS image contains enabled support for automounting GPT partitions marked with the proper GUID (https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html). This automount is triggered by udev anytime GPT partitions are detected. This means that: 1) When deploying whole-disk images with GPT partitions labelled correctly, they can be immediately mounted into an agent. 2) When cleaning a machine which had properly labelled GPT partitions on disk, these partitions will be mounted on boot, before cleaning begins. This gives the potential for Remote Code Execution in the IPA ramdisk, as a user could craft a filesystem to be mounted in the paths systemd looks for units in, and have those units run. In fact, in some situations, this could lead to existing or newly created units (such as the IPA unit itself) being overridden. To fix this, we'll have to modify the CoreOS image during build to disable this autogenerator. This can be done in the current supported version of CoreOS by `chmod 000 /lib64/systemd/system-generators/systemd-gpt-auto-generator` during the image build process. When the CoreOS image is upgraded to a newer version, we should utilize the masking behavior: https://cgit.freedesktop.org/systemd/systemd/commit/?id=e801700e9a to disable the autogenerator as well. (This is not supported in systemd 212, the version currently shipped by IPA). Additionally, there is a functionality bug as well; when this udev event triggers, it causes a remount event which causes all mounts to remount, including those to support the IPA chroot. This would cause cleaning or deploys to fail in these cases. However, as noted above, this does not mitigate the vulnerability in chroot'd IPA ramdisks as the entire set of units used to spawn IPA could be overridden by a well-crafted partition table + filesystem.
2016-06-13 22:41:55 Jim Rollenhagen bug added subscriber Devananda van der Veen
2016-06-14 00:47:06 Jim Rollenhagen bug added subscriber Brad Morgan
2016-06-16 20:11:40 Jay Faulkner summary IPA CoreOS Image mounts GPT disks during cleaning IPA may unexpectedly stop in a CoreOS-based ramdisk in certain circumstances
2016-06-16 20:18:14 Jay Faulkner description The systemd shipped in the upstream, published IPA CoreOS image contains enabled support for automounting GPT partitions marked with the proper GUID (https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html). This automount is triggered by udev anytime GPT partitions are detected. This means that: 1) When deploying whole-disk images with GPT partitions labelled correctly, they can be immediately mounted into an agent. 2) When cleaning a machine which had properly labelled GPT partitions on disk, these partitions will be mounted on boot, before cleaning begins. This gives the potential for Remote Code Execution in the IPA ramdisk, as a user could craft a filesystem to be mounted in the paths systemd looks for units in, and have those units run. In fact, in some situations, this could lead to existing or newly created units (such as the IPA unit itself) being overridden. To fix this, we'll have to modify the CoreOS image during build to disable this autogenerator. This can be done in the current supported version of CoreOS by `chmod 000 /lib64/systemd/system-generators/systemd-gpt-auto-generator` during the image build process. When the CoreOS image is upgraded to a newer version, we should utilize the masking behavior: https://cgit.freedesktop.org/systemd/systemd/commit/?id=e801700e9a to disable the autogenerator as well. (This is not supported in systemd 212, the version currently shipped by IPA). Additionally, there is a functionality bug as well; when this udev event triggers, it causes a remount event which causes all mounts to remount, including those to support the IPA chroot. This would cause cleaning or deploys to fail in these cases. However, as noted above, this does not mitigate the vulnerability in chroot'd IPA ramdisks as the entire set of units used to spawn IPA could be overridden by a well-crafted partition table + filesystem. In some scenarios, such as: 1) Imaging a disk with a recent CoreOS image, or any other image with a partition labelled OEM 2) During a cleaning step refreshing or changing partition tables that include a partition labelled OEM (no shipped cleaning step does this today). Will cause a udev event to trigger, causing systemd to attempt to mount the new partition at /usr/share/oem. This mount will not succeed, due to ConditionPathExists=!/usr/.noupdate not passing, however, when it fails to mount, systemd will unexpectedly unmount /usr/share/oem, causing ironic-python-agent to unexpectedly stop and not complete whatever action was in progress. The most common impact is that it becomes impossible to deploy a CoreOS image using a CoreOS based IPA ramdisk because IPA will stop before completing the deployment.
2016-06-16 20:19:11 Jay Faulkner information type Private Security Public
2016-06-16 20:41:08 Jay Faulkner ironic-python-agent: status New Confirmed
2016-06-16 20:41:11 Jay Faulkner ironic-python-agent: importance Undecided High
2016-06-16 21:12:17 OpenStack Infra ironic-python-agent: status Confirmed In Progress
2016-06-16 21:12:17 OpenStack Infra ironic-python-agent: assignee Brad Morgan (morgabra)
2016-06-17 09:36:37 OpenStack Infra ironic-python-agent: status In Progress Fix Released
2016-06-17 20:20:33 Jay Faulkner ironic-python-agent: status Fix Released In Progress
2016-06-20 10:21:37 Dmitry Tantsur nominated for series ironic-python-agent/mitaka
2016-06-20 10:21:37 Dmitry Tantsur bug task added ironic-python-agent/mitaka
2016-06-20 10:22:30 Dmitry Tantsur nominated for series ironic-python-agent/newton
2016-06-20 10:22:30 Dmitry Tantsur bug task added ironic-python-agent/newton
2016-06-20 10:22:35 Dmitry Tantsur ironic-python-agent/newton: status In Progress Fix Released
2016-06-21 20:52:06 OpenStack Infra ironic-python-agent/mitaka: assignee Brad Morgan (morgabra) Jay Faulkner (jason-oldos)
2016-06-21 23:09:14 OpenStack Infra ironic-python-agent/mitaka: status In Progress Fix Committed
2016-06-22 00:12:34 OpenStack Infra tags in-stable-liberty