Vi ricordate quelle volte in cui abbiamo parlato di Secure Boot? Bene, in qualche modo Redmond ha lasciato sfuggire alcune «chiavi d’oro», che in realtà rappresentano una politica speciale equivalente a una «modalità di sviluppo», la quale a sua volta disattiva diverse funzioni principali di Secure Boot. La parte migliore? Microsoft all’inizio pensava che non fosse un problema, ma ha rilasciato due patch in meno di un mese. È scappato il genio dalla lampada?
Privacy, sicurezza, codice proprietario, open source, jailbreaking, rooting… termini che vanno, vengono, si scontrano, percorrono un cammino simile o si distruggono a vicenda. L’utente medio rimane intrappolato in una tempesta senza sapere cosa sia più conveniente, e le argomentazioni di tutte le parti coinvolte diventano rumore bianco. L’ultima novità che si è appena piazzata sopra questo rumore riguarda Secure Boot, vecchio conoscente di NeoTeo, teorico protettore dell’integrità del computer e del suo sistema operativo (in questo caso specifico, diverse versioni di Windows), e nemico mortale di molti cavalieri di Linux che hanno voluto fare un «dual-boot» sui loro nuovi dispositivi e non ci sono riusciti. Microsoft ha indicato (in più di un’occasione) che i sistemi certificati basati su x86 devono permettere a Secure Boot di entrare in «modalità personalizzata» o dare la possibilità di disattivarlo completamente, anche se ciò non si estende ai dispositivi ARM, una delle ragioni per cui tutti quei tablet con Windows RT sono attualmente poco più che mattoni. Tuttavia, lo stato generale di Secure Boot potrebbe cambiare completamente nel giro di qualche mese.
Cosa è successo esattamente? Due esperti di sicurezza identificati con gli pseudonimi MY123 e Slipstream hanno scoperto qualcosa che hanno battezzato «chiavi d’oro», che non sono chiavi digitali nel senso tradizionale, ma una politica speciale di Secure Boot che modifica i compiti eseguiti da UEFI all’avvio… tra cui il controllo delle firme. A quanto pare, questa politica esiste come una «modalità di sviluppo» o «modalità debug», se preferite, che permette ai programmatori di valutare nuove build, individuare bug e applicare le correzioni necessarie senza dover firmare tutto. Come è arrivata nelle mani di MY123 e Slipstream? Fondamentalmente l’hanno trovata a fine marzo «addormentata» sui dispositivi che Microsoft offre in vendita. Si sono messi in contatto con l’azienda ad aprile, e in quel momento Microsoft ha ritenuto che non fosse un rischio per la sicurezza (richiede accesso fisico “o” privilegi di amministratore), ma tra giugno e luglio hanno deciso di pagare una ricompensa e rilasciare due patch, MS16-094 e MS16-100, che pur mitigando la situazione non presentano una soluzione definitiva.
In cosa si trasformerà tutto ciò? La risposta è «dipende». La politica potrebbe permettere l’installazione di sistemi operativi alternativi su dispositivi con Windows RT (senza gli hotfix menzionati) o Windows Phone. Personalmente mi piacerebbe vedere cosa può fare la comunità (non sarà affatto semplice, anche se là fuori ci sono geni che vivono cercando sfide di questo tipo), ma la medaglia ha due facce. Non è logico creare una lista nera con ogni «bootmgr» interessato perché romperebbe la compatibilità in più di un caso (dischi di installazione originali, partizioni di ripristino, backup, ecc.), e se qualcuno sfrutta questa falla per installare un «pacchetto» malevolo, beh...
(N.d.R.: Sì, la pagina ufficiale assomiglia a un cracktro degli anni ’90)
Sito ufficiale: https://rol.im/securegoldenkeyboot/
Fonte: http://arstechnica.com/security/2016/08/microsoft-secure-boot-firmware-snafu-leaks-golden-key/
