SecureBoot fa parte di UEFI e di altri firmware che possono essere utilizzati per verificare le firme sul software che verrà caricato all'avvio. Di solito è un bootloader, ma può anche essere il sistema operativo stesso.
Su alcune implementazioni l'utente può "masterizzare" un certificato personalizzato per il firmware da utilizzare per la convalida. In altri casi i certificati sono precaricati dal produttore e solo il software da loro firmato può essere utilizzato sul dispositivo.
I dispositivi incorporati come telefoni e tablet di solito rientrano nella seconda categoria, in cui l'utente non può modificare il software installato se non nei casi consentiti dal produttore (ad esempio, un aggiornamento del sistema operativo).
Rompendo questo blocco, gli utenti possono installare qualsiasi cosa vogliano. Questo è solitamente chiamato "jailbreak" del dispositivo.
Il problema con il jailbreaking è che consente anche ai cattivi attori di compromettere il dispositivo a un livello basso, il che rende le minacce più persistenti e difficili da rilevare.
Diversi dispositivi hanno avuto diversi metodi per il jailbreak nel corso degli anni. In questo caso è stato un problema da parte di Microsoft a permetterlo. Da alla scrittura originale (forse NSFW) :
[secure boot policy is] a file in a binary format that's embedded
within an ASN.1 blob, that is signed. It's loaded by bootmgr REALLY
early into the windows boot process. It must be signed by a
certificate in db. It gets loaded from a UEFI variable in the
secureboot namespace (therefore, it can only be touched by boot
services). There's a couple .efis signed by MS that can provision such
a policy, that is, set the UEFI variable with its contents being the
policy.
Questo è uno schema molto intelligente ed estensibile che è stato interrotto da un trascuratezza durante lo sviluppo:
During the development of Windows 10 v1607 'Redstone', MS added a new
type of secure boot policy. Namely, "supplemental" policies that are
located in the EFIESP partition (rather than in a UEFI variable), and
have their settings merged in, dependant on conditions (namely, that a
certain "activation" policy is also in existance, and has been loaded
in).
[...] The "supplemental" policy contains new elements, for the merging
conditions. These conditions are (well, at one time) unchecked by
bootmgr when loading a legacy policy. And bootmgr of win10 v1511 and
earlier certainly doesn't know about them. To those bootmgrs, it has
just loaded in a perfectly valid, signed policy.
In altre parole, hanno un criterio firmato che consente loro di caricare i file binari non firmati, presumibilmente per consentire di testare le versioni di sviluppo senza dover firmare ciascuna.
Hanno spedito accidentalmente questa norma in alcuni dispositivi, qualcuno l'ha scoperta e pubblicata, e ora può essere caricata su qualsiasi dispositivo.
L'articolo contiene molti più dettagli su come funziona. Il punto è che questo è un exploit di jailbreak. Per alcuni è una buona notizia, per gli altri non così tanto.
Lo sfruttamento efficace richiede diritti di amministratore o accesso fisico.
@Bradley ha menzionato nei commenti che "Rende più facile per il malware che è già sul tuo PC prendere il controllo dell'avanzamento e superare completamente il tuo pc". Se è vero, significa che il malware ha già i diritti di amministratore sul dispositivo, quindi il compromesso di avvio è l'ultimo dei tuoi problemi.
Microsoft ha dichiarato:
The jailbreak technique described in the researchers’ report on August
10 does not apply to desktop or enterprise PC systems. It requires
physical access and administrator rights to ARM and RT devices and
does not compromise encryption protections.
Ma potrebbe essere stato un eufemismo. Hanno rilasciato due patch: MS16-094 e MS16-100. Il primo indica:
An attacker must have either administrative privileges or physical
access to install a policy and bypass Secure Boot.
This security update is rated Important for all supported editions of
Windows 8.1, Windows RT 8.1, Windows Server 2012, Windows Server 2012
R2, and Windows 10.
[...]
The security update addresses the vulnerability by blacklisting
affected policies.
Quindi è uno root o accesso fisico, come menzionato prima.
E fa influisce sui desktop e sui server (vedi la discussione dei commenti per la speculazione sul motivo per cui avrebbero potuto dire che non ha funzionato).
Inoltre, la lista nera delle policy è stata giudicata insufficiente: il rollback a un bootmgr precedente poteva ancora consentire il caricamento del criterio (questo è menzionato nel write up). Anche la seconda patch oscura i vecchi boot manager per risolverli.
TL; DR : correggi i tuoi sistemi Windows e non preoccuparti troppo di questo. Ci sono problemi ben peggiori.