S'ha revelat informació sobre 8 vulnerabilitats al carregador d'arrencada GRUB2, que us permeten evitar el mecanisme d'arrencada segura UEFI i executar codi no verificat, per exemple, implementar programari maliciós que s'executa al nivell del carregador d'arrencada o del nucli.
Recordem que a la majoria de distribucions de Linux, per a l'arrencada verificada en mode d'arrencada segura UEFI, s'utilitza una petita capa de compensació, signada digitalment per Microsoft. Aquesta capa verifica GRUB2 amb el seu propi certificat, que permet als desenvolupadors de distribució no tenir tots els nuclis i les actualitzacions de GRUB certificats per Microsoft. Les vulnerabilitats de GRUB2 us permeten assolir l'execució del vostre codi en l'etapa després de la verificació correcta del shim, però abans de carregar el sistema operatiu, encaixar a la cadena de confiança quan el mode d'arrencada segur està actiu i obtenir el control total sobre el procés d'arrencada posterior, inclòs carregar un altre sistema operatiu, modificar el sistema de components del sistema operatiu i evitar la protecció de bloqueig.
Igual que amb la vulnerabilitat BootHole de l'any passat, l'actualització del carregador d'arrencada no és suficient per bloquejar el problema, ja que un atacant, independentment del sistema operatiu utilitzat, pot utilitzar suports d'arrencada amb una versió antiga, signada digitalment i vulnerable de GRUB2 per comprometre l'arrencada segura UEFI. El problema només es pot resoldre actualitzant la llista de revocació de certificats (dbx, UEFI Revocation List), però en aquest cas es perdrà la possibilitat d'utilitzar mitjans d'instal·lació antics amb Linux.
En sistemes amb microprogramari que tinguin una llista de revocació de certificats actualitzada, només es poden carregar les compilacions actualitzades de distribucions de Linux en mode d'arrencada segura UEFI. Les distribucions hauran d'actualitzar els instal·ladors, els carregadors d'arrencada, els paquets del nucli, el microprogramari fwupd i la capa shim, generant noves signatures digitals per a ells. Els usuaris hauran d'actualitzar les imatges d'instal·lació i altres mitjans d'arrencada, així com carregar una llista de revocació de certificats (dbx) al microprogramari UEFI. Abans d'actualitzar dbx a UEFI, el sistema segueix sent vulnerable independentment de la instal·lació d'actualitzacions al sistema operatiu. L'estat de les vulnerabilitats es pot avaluar a aquestes pàgines: Ubuntu, SUSE, RHEL, Debian.
Per resoldre els problemes que sorgeixen en la distribució de certificats revocats, en el futur està previst utilitzar el mecanisme SBAT (UEFI Secure Boot Advanced Targeting), suport per al qual s'ha implementat per a GRUB2, shim i fwupd, i a partir de les properes actualitzacions es farà. utilitzat en lloc de la funcionalitat proporcionada pel paquet dbxtool. SBAT es va desenvolupar conjuntament amb Microsoft i implica afegir noves metadades als fitxers executables dels components UEFI, que inclou informació sobre el fabricant, producte, component i versió. Les metadades especificades estan certificades amb una signatura digital i, a més, es poden incloure a les llistes de components permesos o prohibits per a l'arrencada segura UEFI. Així, SBAT us permetrà manipular els números de versió dels components durant la revocació sense necessitat de regenerar les claus per a l'arrencada segura i sense generar noves signatures per al nucli, shim, grub2 i fwupd.
Vulnerabilitats identificades:
- CVE-2020-14372: utilitzant l'ordre acpi de GRUB2, un usuari amb privilegis del sistema local pot carregar taules ACPI modificades col·locant una SSDT (taula de descripció del sistema secundària) al directori /boot/efi i canviant la configuració a grub.cfg. Tot i que el mode d'arrencada segur està actiu, l'SSDT proposat l'executarà el nucli i es pot utilitzar per desactivar la protecció de bloqueig que bloqueja els camins de derivació de l'arrencada segura UEFI. Com a resultat, un atacant pot aconseguir carregar el seu mòdul del nucli o executar codi mitjançant el mecanisme kexec, sense comprovar la signatura digital.
- CVE-2020-25632 és un accés a memòria lliure d'ús en la implementació de l'ordre rmmod, que es produeix quan s'intenta descarregar qualsevol mòdul sense tenir en compte les dependències associades a aquest. La vulnerabilitat no exclou la creació d'un exploit que pugui provocar l'execució de codi sense passar per la verificació d'arrencada segura.
- CVE-2020-25647 Una escriptura fora de límits a la funció grub_usb_device_initialize() cridada en inicialitzar dispositius USB. El problema es pot aprofitar connectant un dispositiu USB especialment preparat que produeixi paràmetres la mida dels quals no es correspon amb la mida del buffer assignat a les estructures USB. Un atacant pot aconseguir l'execució de codi que no es verifica a l'arrencada segura manipulant dispositius USB.
- CVE-2020-27749 és un desbordament de memòria intermèdia a la funció grub_parser_split_cmdline(), que es pot provocar especificant variables més grans d'2 KB a la línia d'ordres GRUB1. La vulnerabilitat permet que l'execució de codi passi per alt l'arrencada segura.
- CVE-2020-27779: l'ordre cutmem permet a un atacant eliminar una sèrie d'adreces de la memòria per evitar l'arrencada segura.
- CVE-2021-3418: els canvis a shim_lock van crear un vector addicional per explotar la vulnerabilitat CVE-2020-15705 de l'any passat. En instal·lar el certificat utilitzat per signar GRUB2 a dbx, GRUB2 va permetre que qualsevol nucli es carregués directament sense verificar la signatura.
- CVE-2021-20225 - Possibilitat d'escriure dades fora dels límits quan s'executen ordres amb un nombre molt gran d'opcions.
- CVE-2021-20233 - Possibilitat d'escriure dades fora dels límits a causa d'un càlcul incorrecte de la mida del buffer quan s'utilitzen cometes. A l'hora de calcular la mida, es va suposar que es necessitaven tres caràcters per escapar d'una cometa, quan de fet se'n requerien quatre.
Font: opennet.ru