Skip to content
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

Closed
bgilbert opened this issue Nov 1, 2022 · 7 comments
Assignees

Comments

@bgilbert
Copy link
Member

bgilbert commented Nov 1, 2022

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:

  • stable 36.20220820.3.0 and later
  • testing 36.20220906.2.0 and later
  • next 36.20220906.1.0 and later

If 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:

sudo ostree config set sysroot.bls-append-except-default 'grub_users=""'
sudo unshare -mw /boot/loader/entries bash -c \
    'mount -o rw,remount /boot &&
     for f in $(ls -v ostree-*-fedora-coreos.conf | head -n -1); do
         if ! grep -q grub_users "$f"; then
             echo grub_users \"\" >> "$f";
         fi;
     done'

To check which version of Fedora CoreOS was used to provisioned a machine, run the following command:

jq -r .build /sysroot/.coreos-aleph-version.json
@bgilbert bgilbert self-assigned this Nov 1, 2022
bgilbert pushed a commit to bgilbert/coreos-assembler that referenced this issue Nov 1, 2022
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
bgilbert added a commit to bgilbert/fedora-coreos-config that referenced this issue Nov 1, 2022
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.
bgilbert added a commit to bgilbert/fedora-coreos-config that referenced this issue Nov 1, 2022
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.
@bgilbert
Copy link
Member Author

bgilbert commented Nov 1, 2022

coreos-status post.

bgilbert pushed a commit to coreos/coreos-assembler that referenced this issue Nov 1, 2022
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
bgilbert added a commit to coreos/fedora-coreos-config that referenced this issue Nov 2, 2022
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.
@bgilbert bgilbert added status/pending-testing-release Fixed upstream. Waiting on a testing release. status/pending-next-release Fixed upstream. Waiting on a next release. labels Nov 2, 2022
@dustymabe
Copy link
Member

The fix for this went into next stream release 37.20221031.1.0. Please try out the new release and report issues.

@dustymabe
Copy link
Member

The fix for this went into testing stream release 36.20221030.2.1. Please try out the new release and report issues.

@dustymabe dustymabe added status/pending-stable-release Fixed upstream and in testing. Waiting on stable release. and removed status/pending-testing-release Fixed upstream. Waiting on a testing release. status/pending-next-release Fixed upstream. Waiting on a next release. labels Nov 2, 2022
@dustymabe
Copy link
Member

The fix for this went into stable stream release 36.20221030.3.0.

@dustymabe dustymabe removed the status/pending-stable-release Fixed upstream and in testing. Waiting on stable release. label Nov 15, 2022
@dustymabe
Copy link
Member

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 testing for the F37 transition already happened in coreos/fedora-coreos-streams@8679f68

The barrier for stable will come through in the next release on that stream (since we're switching to F37 there too).

That leaves next. Since we had already switched to F37 in next before this landed we need a new barrier there so I'll add one.

@dustymabe
Copy link
Member

OK removing the migration script should be unblocked now.

dustymabe added a commit to dustymabe/fedora-coreos-config that referenced this issue Nov 17, 2022
…-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)
@dustymabe
Copy link
Member

revert in coreos/fedora-coreos-config#2095

jlebon pushed a commit to coreos/fedora-coreos-config that referenced this issue Nov 18, 2022
…-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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants