Secure Boot: troppo facile da aggirare

Edit: prontamente, subito prima di pubblicare questo articolo, ho fatto un upgrade totale con pacman -Syu come avevo fatto più volte con vari aggiornamenti del kernel nel mezzo e questi aggiornamenti non sovrascrivono il bootloader o PreLoader o cose del genere.
Prontamente, “Boot failed: Access denied”, con una grafica diversa da quella del BIOS buggato che lo dice a prescindere anche se poi lascia avviare. E dopo un laggone bestiale in cui sembra che tutto si sia piantato, si apre l’HashTool da solo. Deduco che a generare l’errore adesso è PreLoader, che non ho aggiornato perché dovrei copiare a mano i file in /boot per aggiornarlo, quindi non so che diamine stia succedendo.

Alla fine, differentemente da tutte le altre volte, è stato necessario aggiungere l’hash di /boot/vmlinuz-linux alle MOK, cosa che non avevo mai fatto, ricordo benissimo.
O mi sta andando in pappa il cervello e ricordo male, o il metodo non funziona più. Nel dubbio lo pubblico comunque.

Inoltre, qualcuno ha descritto la procedura anche sulla wiki ufficiale di Arch, con annesso workaround per BIOS ancora più buggati dove il menu di avvio nella NVRAM è puramente decorativo perché avviano solo il bootloader di Windows riconoscendolo dal nome del file.
Ormai l’articolo l’ho scritto quindi, reitero, lo pubblico comunque.


Nell’ultima puntata: il dannato notebook può avviare solo con UEFI, solo con Secure Boot e solo con la chiave Microsoft.

Forse si può sostituire la PK usando il KeyTool ma non sono interamente sicuro che sia possibile o ragionevole da fare, visto che non c’è verso di attivare la Setup Mode e non ho voglia di rovistare ancora tra le frammentarie informazioni presenti su internet per capire se basta firmare il kernel con la PK o se bisogna per forza passare dalle altre chiavi, cioè dalla chiave Microsoft.

Se è obbligatorio usare quest’ultima, cosa succede se la chiave privata Microsoft cade in mano a dei malintenzionati: si può revocare? E se sì, io poi cosa avvio? O continuo a usare software firmato con una chiave non sicura, vanificando completamente l’aspetto Secure che compone metà del nome Secure Boot, o non avvio più nulla perché non posso caricare altre chiavi. Vanificando l’aspetto Boot, che è pure peggio.

Ma insomma, abbiamo già perso troppo tempo, vediamo come aggirare Secure Boot per avviare Linux senza neanche firmare i kernel o aggiungerne l’hash alle MOK.

La procedura è stata descritta dall’utente shvr di Reddit, io mi limito a tradurla e rimaneggiarla un po’.

  1. Installare Arch Linux, attenersi alla wiki. Poiché se stai leggendo questa guida hai Secure Boot non disattivabile, i seguenti passi vanno compiuti dalla Live, ma nella “chroot” del sistema appena installato. Usare lo script arch-chroot o quello che la wiki consiglia, se dovesse cambiare.
  2. Scaricare prebootloader. Ovvero fare: pacman -Sy && pacman -S prebootloader. Prima o poi può essere il caso di configurare pacman per verificare le firme dei pacchetti, ma non ho ancora capito se sulla Live sia già fatto o no…
  3. Copiare i file .efi da /usr/lib/prebootloader nella cartella del bootloader, che se è systemd-boot allora è /boot/EFI/systemd.
    Fin qui ricorda vagamente i passaggi che ho già descritto per avviare il KeyTool, perché in fin dei conti sono gli stessi.
  4. Rinominare il file .efi del bootloader in loader.efi. Con systemd-boot è /boot/EFI/systemd/systemd-bootx64.efi.
  5. Visto che siamo qui, volendo si possono creare delle entry nel menu del bootloader per HashTool e KeyTool, non si sa mai che possano servire…
  6. Usare efibootmgr per aggiungere una entry nel menu. Fare riferimento alla wiki, ma il comando probabilmente è efibootmgr -c -d /dev/sda -p 1 -l /EFI/systemd/PreLoader.efi -L “PreLoader”
    -d /dev/sda -p 1 perché /dev/sda1 è la partizione montata su /boot, identificata con findmnt /boot (a me findmnt /boot/efi, consigliato dalla wiki, non funziona), /EFI/systemd/PreLoader.efi è il percorso di quel file in /boot, “PreLoader” è il nome che avrà questa entry nel menu UEFI.
  7. Riavviare.
  8. “loader.efi failed to execute”: fare enroll hash per loader.efi. Fine.

In pratica, questo abominevole trabiccolo di software, avvia UEFI che avvia PreLoader, che è un software firmato con la chiave Microsoft quindi siamo tutti felici e contenti e parte.

PreLoader lancia poi systemd-boot, che dovrebbe prendersi la briga di controllare a sua volta se il kernel è stato firmato nella maniera rituale, ma non lo fa ed è giusto che sia così, altrimenti staremmo compiendo atti di masochismo estremo e non aggirando Secure Boot.
L’unico hash nelle MOK è quello di qualche componente di systemd-boot, rinominato in loader.efi. Systemd-boot può avviare praticamente quello che vuole, a questo punto: qualsiasi kernel Linux concepibile da mente umana, il KeyTool, la UEFI Shell, qualsiasi sistema operativo (basta che sia supportato da systemd-boot, immagino), pure del malware volendo…
O almeno credo. I kernel Linux non necessitano più di aggiungere hash alle MOK, per i file .efi in verità non ricordo.

Insomma, basta agganciare un bootloader all’altro (PreLoader è quasi un bootloader) per aggirare questo imponente sistema di sicurezza che nelle sue implementazioni pezzenti e buggate oltre ogni limite avvantaggia solo Microsoft.
Edit: nuovamente, a scanso di equivoci, era così. Adesso bisogna firmare tutto. Non so perché. Io odio Secure Boot.

Spero solo che questo metodo sia quello previsto e accettabile di usare PreLoader, e non sia un oscuro trucchetto noto ai pochi adepti che sono discesi nelle profondità abissali delle pagine di risultati su Google. Ovvero che Microsoft non decida di revocare la firma a PreLoader per una cosa del genere.

Su internet ho trovato esattamente solo un’altra persona che suggerisce di usare il trucchetto, e il post sul blog di quello che credo sia uno degli sviluppatori del “Linux Foundation UEFI secure boot system” (cioè PreLoader e compagnia) in cui dice che Microsoft non ha firmato il KeyTool perché permette di eliminare la PK su alcune “piattaforme” (BIOS?) buggate.

Chissà se è per quello che KeyTool mi permette di eliminare la PK? Che mi sia capitato tra le mani un computer con quel bug, oltre alla valanga di altri bug e idiozie che l’OEM si è impegnato a introdurre nel BIOS\UEFI e dintorni?

Annunci

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione /  Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...