Response to CVE-2020-10713 (GRUB 2 Boot Hole)

[jlebon]

See: https://access.redhat.com/security/vulnerabilities/grub2bootloader

We should probably send an email to the mailing list to provide recommendations. We're in the same boat as RHCOS here, in that the bootloader isn't automatically updated.

We can match RHCOS and say "reprovision", though would be nice if we could also provide instructions for how to manually update the bootloader too.

[cgwalters]

This is my opinion: No one should apply this update in a panic. Secure Boot today only comes into play if someone has already compromised a system with root-equivalent privileges. Everyone should continue to focus on preventing that scenario - apply security updates, verify integrity of privileged (and all) software, ensure systems administrators are using multi-factor authentication - the list goes on.

There are also reports of regressions in booting on some machines in response to this: https://bugzilla.redhat.com/show_bug.cgi?id=1861977

Also, it doesn't look like there are any Fedora builds for this yet AFAICS. The last grub build was a month ago, and last shim build was much longer ago than that.

But once those happen and Fedora makes updates FCOS should pick this change up as part of the next release, and FCOS users should consider implementing a "periodic rolling reprovisioning" strategy if they haven't already. (For example, re-PXE a metal server after it's been up for more than 2 months, delete cloud images after a likely shorter period of time too and scale up a new one in its place, etc.)

[jlebon]

Thanks for the perspective. Once FCOS ships the fixed bootloader binaries, do you (or anyone else) have opinions about whether we should provide a manual update path?

My personal opinion is that we should because unlike RHCOS, FCOS is friendlier to the single node/pet path, even if we try to steer people towards Ignition as source of truth.

[cgwalters]

Well I was working on https://github.com/coreos/bootupd to enable both manual and automatic updates. But it needs a lot of work and care. It is certainly tempting to make a "script" just for this one event.

One thing that probably needs to be designed in is tooling to boot from a Live ISO and downgrade for situations like boot regression above.

[dustymabe]

We discussed this in the meeting today.

We were lucky enough in our meeting to be joined by @vathpela who gave us some good information. Summary:

• Sometime over the next few weeks Fedora will ship and updates for dbx as a file on the filesystem, but won't apply it by default.
  • This gives users the opportunity to opt-in to the update by applying the dbx in the delivered files.
• Users that consider themselves a "high value target" may want to apply the update.
  • If they choose to apply the update they should apply it first on a single machine of each class of hardware they have to make sure it applies smoothly before rolling it out to the rest of their fleet.
• OSTree based systems don't currently update the bootloader after it is installed.
  • Eventually we'll have a tool for this (see Design tooling to ship bootloader updates #510).
  • In the mean time we'll offer users two options for applying the update:
    • Re-provision. This option always exists.
    • Documented manual steps to run.

[cgwalters]

https://github.com/coreos/bootupd/ is now in "stable preview" and shipping in FCOS.
coreos/fedora-coreos-docs#203 is pending merge once bootupd 0.2.2 from the testing stream hits stable.

The updated grub that fixes this seems to be https://bodhi.fedoraproject.org/updates/FEDORA-2020-e87e901a8d
which is also in the testing stream.