New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non-default OSTree deployments accessible without GRUB password (CVE-2022-3675) #1333
Comments
The conditional always failed since it's not a valid command without the brackets. So the `sysroot.bls-append-except-default` option was not set in builds created by affected cosa versions. This means that on systems provisioned from those releases with a GRUB password set, unprivileged GRUB users can boot non-default GRUB menu entries without entering a password. Fixes: b4cb857 ("create_disk: Fix s390x regression from previous change") For: coreos/fedora-coreos-tracker#1333
Starting with FCOS 36.20220906.1.0, 36.20220906.2.0, and 36.20220820.3.0, coreos-assembler inadvertently failed to configure ostree to set `grub_users=""` in non-default BLS configs, allowing old deployments to be booted without a GRUB password. Add a service that fixes this setting on the first boot after upgrade, if the aleph version corresponds to an affected release. This can be reverted after the next update barrier in all streams. For coreos/fedora-coreos-tracker#1333.
Starting with FCOS 36.20220906.1.0, 36.20220906.2.0, and 36.20220820.3.0, coreos-assembler inadvertently failed to configure ostree to set `grub_users=""` in non-default BLS configs, allowing old deployments to be booted without a GRUB password. Add a service that fixes this setting on the first boot after upgrade, if the aleph version corresponds to an affected release. This can be reverted after the next update barrier in all streams. For coreos/fedora-coreos-tracker#1333.
The conditional always failed since it's not a valid command without the brackets. So the `sysroot.bls-append-except-default` option was not set in builds created by affected cosa versions. This means that on systems provisioned from those releases with a GRUB password set, unprivileged GRUB users can boot non-default GRUB menu entries without entering a password. Fixes: b4cb857 ("create_disk: Fix s390x regression from previous change") For: coreos/fedora-coreos-tracker#1333
Starting with FCOS 36.20220906.1.0, 36.20220906.2.0, and 36.20220820.3.0, coreos-assembler inadvertently failed to configure ostree to set `grub_users=""` in non-default BLS configs, allowing old deployments to be booted without a GRUB password. Add a service that fixes this setting on the first boot after upgrade, if the aleph version corresponds to an affected release. This can be reverted after the next update barrier in all streams. For coreos/fedora-coreos-tracker#1333.
|
The fix for this went into |
|
The fix for this went into |
|
The fix for this went into |
|
Before we can pull out the migration script from our code base we need it to be in at least one barrier release. The barrier for The barrier for That leaves |
|
OK removing the migration script should be unblocked now. |
…-2022-3675)" This reverts commit d7d4068. This is no longer needed since we have implemented a barrier on each release stream now: coreos/fedora-coreos-tracker#1333 (comment)
|
revert in coreos/fedora-coreos-config#2095 |
…-2022-3675)" This reverts commit d7d4068. This is no longer needed since we have implemented a barrier on each release stream now: coreos/fedora-coreos-tracker#1333 (comment)
Fedora CoreOS recently added support for setting a GRUB password. When this feature is enabled, GRUB requires a password to access the GRUB command-line, modify kernel command-line arguments, or boot non-default OSTree deployments.
Recent Fedora CoreOS releases have a misconfiguration which allows booting non-default OSTree deployments without entering a password. This allows someone with access to the GRUB menu to boot into an older version of Fedora CoreOS. A password is still required to modify kernel command-line arguments and to access the GRUB command line.
Machines provisioned from the following Fedora CoreOS releases are affected:
stable36.20220820.3.0 and latertesting36.20220906.2.0 and laternext36.20220906.1.0 and laterIf you do not use the GRUB password feature, or if you do use it and have provisioned your machines from unaffected Fedora CoreOS images, no action is required.
If your machines are affected, and you are willing to wait for the problem to be corrected automatically in upcoming releases, no action is required. Otherwise, you can correct the problem manually by running the following commands on affected machines:
To check which version of Fedora CoreOS was used to provisioned a machine, run the following command:
The text was updated successfully, but these errors were encountered: