The UEFI 9/11 - Part V - This is Not a Drill (Disable "SecureBoot" Now)
A "9/11" Coming (Next Thursday)
In Part I we introduced the issues in simple terms, in Part II we focused on the attacks on people who merely talked about these issues, Part III primarily tied things together, and Part IV named some of the culprits, which are not limited to Microsoft. IBM/Red Hat also played and still plays a role.
A few years ago Hack-a-day wrote about the blackbox at the heart of all this. It's basically proprietary code that you cannot audit or change to solve issues. Quoting the site: "The biggest complaint with UEFI is that it is a closed black box with unimaginable access to your computer and stays resident after the computer boots. BIOS is appealing since the interface is well-known and generally is non-resident. UEFI can be updated easier but also has a much more vital need for updates. A UEFI update can brick your system entirely. It will not boot, and due to the fuses being blown on the unit, it is almost physically impossible to fix it, even for the manufacturer. Significant amounts of testing go into these updates, but most are hesitant to push many updates because of the amount of work required."
Notice how they didn't warn about the certificate's expiration and some projects are calling all their keys "certificates" (certificates are keys signed by other keys). As Wikipedia puts it: "The certificate includes the public key and information about it, information about the identity of its owner (called the subject)..."
Further down it it says: "Certificate authorities are also responsible for maintaining up-to-date revocation information about certificates they have issued, indicating whether certificates are still valid. They provide this information through Online Certificate Status Protocol (OCSP) and/or Certificate Revocation Lists (CRLs)."
Now consider this comment from LWN: "I have (not so) fond memories of old BIOS systems where removing the battery would reset both the settings and clock. I'm not sure if this is still a thing. Does Secure Boot prevent an attacker from turning the clock back; is there maybe some internal clock that cannot be tampered with? Can one not boot a system the firmware accepts today, reset this firmware clock, and then merrily go on to boot payloads signed with the expired key? Some embedded systems burn fuses to prevent firmware rollbacks, but that's based on version numbers of a fixed boot chain, instead of certificates that might sign arbitrary payloads. I can't see how this sort of hard anti-rollback would work for secure boot, but I'm not sure how much certificate expiration is worth if you don't have a trusted clock."
The comments thread is already infested with Microsoft staff and other Microsofters (covering up their own misdeeds), but the general consensus is, there's no simple workaround or fix. Worse yet, trying to fix this may instead break the system entirely.
One person wrote: "So hardware with vendors who went out of business before now, or with incompetent vendors, will need to disable SecureBoot permanently." █
Related: "The UEFI Restricted Boot 'Time Bomb' is About to Go Off in a Few Weeks"