A che serve utilizzare un sistema operativo open source e sicuro se lo si sta eseguendo su una macchina con firmware a sorgente chiuso?

Storicamente, il movimento open source non riguarda la sicurezza ma la libertà . Fondamentalmente, Richard Stallman era molto preoccupato di non essere in grado di armeggiare con la sua stampante perché la fonte del driver non era disponibile.

La posizione di OpenBSD sull'essere "sicuro" non deriva dal fatto che sia open source, ma da un obiettivo dichiarato e si impegna a fare le cose correttamente per quanto riguarda la sicurezza (storicamente, OpenBSD è nato perché alcuni sviluppatori di NetBSD erano molto meglio nella programmazione che nella gestione delle relazioni pacifiche uomo-uomo).

L'associazione tra sicurezza e open source è più recente. Infatti, fin dall'inizio, è stato spiegato come un concetto incompleto (vedere il famoso Riflessioni su Trust Trust ). Un elemento della discussione è la legge di Linus che dice:

given enough eyeballs, all bugs are shallow

L'idea di base è che, con un numero sufficiente di revisori, verranno trovati bug e questo si estende ai bug relativi alla sicurezza. Ciò vale, tuttavia, solo sulla premessa che ci sono revisori. Il software open source semplifica le revisioni esterne, ma ciò non significa che le revisioni esterne avvengano effettivamente. Quando è stata l'ultima volta che hai esaminato il codice sorgente esistente?

Caso in questione: OpenSSL. Dopo l'individuazione di un'altra vulnerabilità nel codice base, è stato creato un fork, denominato LibreSSL , che ha avviato uno sforzo esplicito di revisione , che ha riscontrato diversi problemi gravi nella base del codice. Questi problemi esistevano da anni, proprio nel mezzo di una biblioteca che si può dire che sia una delle librerie più importanti per la sicurezza nell'ecosistema Linux. Quindi questo era open source, e tuttavia non sufficiente (del tutto) per ottenere un rilevamento della vulnerabilità adeguato.

Quindi ovviamente l'open-sourceness aiuta con la sicurezza, ma non quanto si possa sperare.

Ciò che l'open source apporta veramente è un rischio molto più elevato per le persone che vogliono piazzare intenzionalmente backdoor. È difficile rendere il codice apparentemente innocuo per i revisori e fa ancora cose cattive (esiste un concorso per tale codice).

L'open source non è inequivocabilmente = più sicuro / sicuro

Chiunque CAN guarda hardware / software open source, ma ciò non garantisce che "chiunque" WILL la guardi; inoltre, se lo guardano, ciò non significa nemmeno che riveleranno qualcosa che trovano che potrebbe essere una vulnerabilità. Le persone danno troppo per l'open source e uno degli errori che credono è che se un gruppo di persone può guardare a qualcosa che è improvvisamente più sicuro e più sicuro. Questo non è inequivocabilmente vero. È bello poter avere molti occhi sul prodotto, ma l'etica e la morale di quegli occhi mi preoccupano tanto quanto la loro abilità tecnica.

Detto questo, ci sono molti vantaggi dell'open source se il concetto alla base è implementato correttamente.

Inoltre, closed source non automaticamente = meno sicuro / non sicuro.

Ma per rispondere direttamente alla tua domanda, no non sconfiggi automaticamente lo scopo di utilizzare un SO noto che riguarda la sicurezza come OpenBSD eseguendolo su hardware closed source poiché l'hardware stesso potrebbe avere molto codice di sicurezza / firmware dietro di esso tanto quanto qualcosa di aperto potrebbe.

Lasciando da parte l'argomento "open source == secure", puoi anche considerare questa domanda come "Perché eseguire un SO sicuro quando il BIOS / firmware non è garantito come sicuro".

Perché preoccuparsi di chiudere la porta principale quando un utente malintenzionato può semplicemente rompere i vetri?

Non realizzerai mai un sistema completamente sicuro. Quello che puoi fare è assicurarti di lavorare sulla messa in sicurezza delle parti che possono essere sfruttate facilmente da un attaccante. È molto più lavoro fare exploit firmware, e si limitano a puntare su un determinato modello di hardware. Mentre un bug del sistema operativo è più facile da sfruttare e colpisce una base di target più ampia.

Quindi sì, idealmente vuoi entrambi, ma avere uno solo non è inutile.

Il software open source (free / libre) non è (principalmente) sulla sicurezza. Uno dei suoi aspetti più importanti è la fiducia : puoi verificare cosa è in esecuzione, è molto più difficile nascondere qualcosa di malevolo. Alcune persone sostengono inoltre che più persone leggeranno il codice (potrebbe), il che significa che è probabile che vengano scoperte e risolte maggiori vulnerabilità, con conseguente aumento della qualità del codice. Questo è già stato discusso in profondità nella risposta di Tom Leek. Non approfondirò questo argomento discutibile in questa risposta, poiché la tua domanda non riguarda il motivo per cui il software open source è più sicuro, ma perché preoccuparsi del fatto che il firmware sia closed source.

Mettendo da parte il fatto che anche il software open source non è necessariamente sicuro, eseguirà un codice attendibile su un firmware non affidabile che non renderà l'esecuzione del codice non affidabile? Certo! Ma il vettore di attacco è potenzialmente più piccolo. È molto più difficile accedere alle interfacce del firmware del dispositivo rispetto all'accesso al sistema operativo e al software applicativo del computer, che potrebbero anche fornire servizi su Internet (e molte altre interfacce per completare estranei). Non ci sarà mai piena sicurezza, ma puoi provare a ridurre al minimo il rischio entro un determinato budget.

Con uno sforzo adeguato, il firmware closed source (UEFI / BIOS) può essere sostituito con un software open source : Coreboot è un ottimo esempio che implementa un firmware aperto per alcuni prodotti. Ma il UEFI / BIOS non è l'unico firmware : i BLOB come il motore di gestione di Intel a volte sono ancora necessari, i dispositivi hardware come schede grafiche e di rete hanno firmware, il tuo disco rigido è caricato, c'è persino il microcodice caricato PROCESSORE. E tutti hanno un controllo più o meno arbitrario sulla memoria e / o sull'archiviazione. Infine, si potrebbe persino diffidare del fornitore della CPU, che potrebbe implementare circuiti dannosi con hardware semplice.

Devi fermarti ad un certo punto e fidarti semplicemente del venditore , poiché i costi aumentano notevolmente man mano che si scende più in profondità verso l'hardware. Hai la capacità di verificare finalmente una complessa progettazione della CPU e di produrre la CPU da sola?

Al Chaos Communicaiton Congress 2015 (32C3), ci fu un ottimo discorso su come ottenere Verso (ragionevolmente) computer portatili x86 affidabili , fornendo un riepilogo sull'argomento.

Non ci sono cose come la piena sicurezza, ma si può rendere più difficile rompere la sicurezza. Mentre sarebbe possibile compromettere il sistema dall'interno del BIOS, UEFI, Intel SME, BIOS della rete o delle schede grafiche, CPU Microcode, cattivo design della CPU ... questo è molto più difficile che usare un bug in un programma spaziale dell'utente o il kernel del sistema operativo. Quindi i ragazzi di OpenBSD si preoccupano dei problemi che possono risolvere e che davvero aiutano. Ciò non significa che non siano a conoscenza degli altri problemi.

Ci sono sempre livelli più profondi da considerare e gli utenti devono scegliere dove fermarsi.

• Molti chip hanno un firmware / BIOS non infiammabile. Lo vuoi, anche se non potresti mai modificarlo?
• E il microcodice del tuo processore? Questo può essere sostituito (ed è)
• E il microcode non modificabile del tuo processore / GPU / ...?

L'unico modo per essere "veramente sicuri" sarebbe avere il design esatto di ogni chip della tua macchina, e un modo per verificare che i chip fisici abbiano quel design esatto, ma nessuna Intel / AMD non ti darebbe mai questo, c'è sempre un blocco di cui non ti puoi fidare.

Il firmware è tipicamente accoppiato con l'hardware, e nella maggior parte delle situazioni si è costretti a fidarsi dell'hardware (per mancanza di un'alternativa migliore). Così finisci per fidarti del firmware.

Non che questa sia una buona cosa - la fiducia non è mai in InfoSec! Ma se ti fidi dell'hardware, non guadagni troppo senza fidarti del firmware. Se vuoi spaventarti su questo argomento, guarda Ralf Weinmann parlare del software in banda base che ogni telefono ha ma nessuno pensa mai: link

Si tenga presente che la recente complessità del software BIOS (vale a dire che è vulnerabile agli attacchi) è un nuovo sviluppo relativo alla cronologia del campo. A causa di ciò, esistono pochissime valutazioni complete delle minacce per BIOS e firmware. Per realizzare una situazione di sicurezza, è necessario utilizzare sia il firmware sicuro, sia aperto o chiuso, e un sistema operativo sicuro. L'utilizzo di un BIOS sicuro e chiuso e di un sistema operativo open source sicuro è un'opzione perfettamente ragionevole.

Come è già stato detto, l'open source non è uguale alla sicurezza. L'open source è tremendamente trasparente, il che può essere di aiuto nella revisione, ma presuppone che la revisione venga eseguita. Suppone anche che la revisione venga eseguita tenendo conto dei tuoi interessi. Viene esaminato a un livello di cui ti fidi.

In molti laboratori governativi, il codice open source è in realtà non affidabile . Si fidano di più del codice closed source commerciale. Ci sono molte ragioni, ma una che è particolarmente rilevante qui è che il codice commerciale chiuso ha una società commerciale dietro di esso. Se hanno particolari problemi di sicurezza che desiderano affrontare, può essere più facile lavorare con un'azienda per risolvere i problemi di quanto non lo sarebbe assumere il proprio esperto per fare la recensione. D'altra parte, non esiste un'azienda che produce un prodotto open source, quindi può essere molto difficile convincere la legione di revisori che esaminano il codice open source per esaminare i vostri particolari problemi. Hanno scoperto che, nel caso di avversari che scrivono intenzionalmente backdoor che hanno come target loro , piuttosto che bersagliare qualsiasi utente arbitrario, è molto più facile introdursi nell'open source e spesso non vengono presi in esame. Un'azienda ha molto più da perdere permettendo alle backdoor di ferire i propri clienti rispetto a un programmatore che scrive open source nel tempo libero.

Anche se non ti fidi del firmware, essere in grado di fidarsi del sistema operativo (e delle applicazioni) aumenta la fiducia complessiva che puoi avere nel sistema.

Inoltre, il firmware è raramente utilizzato (se non mai) oltre all'avvio del sistema e le probabilità che una vulnerabilità o una backdoor si ripercuota correttamente sul sistema operativo una volta che è attiva e in esecuzione sono quasi nulla.

Ti ricordo che non devi permettere che il perfetto sia il nemico del bene.

Sì, OpenBSD è a rischio perché funziona su firmware closed source. C'è un po 'di catch-22 qui. Le piattaforme hardware closed source costituiscono la maggior parte di ciò che è commercialmente disponibile sul mercato aperto. Quindi, se vuoi che le persone utilizzino il tuo software / siano di servizio a chiunque altro, dovrai eseguire alcuni di questi firmware.

Dal punto di vista della sicurezza, possono risolvere molti problemi con la sicurezza del software scrivendo ed eseguendo il software OpenBSD. Gli exploit che esistono nel firmware sono di solito eseguiti da un piccolo gruppo selezionato di persone (la maggior parte degli attacchi firmware sono molto più specializzati).

Dato un sistema operativo open source, i gruppi hardware open source possono iniziare con una base software conosciuta. Senza una grande base di capitale, la costruzione di entrambi allo stesso tempo è proibitiva (la maggior parte degli anni OpenBSD ha a malapena la base per il software che scrive).

Fino a quando esiste una buona e economica soluzione hardware open source, lamentando che le persone non stanno utilizzando una soluzione hardware open source sembra come sputare sotto la pioggia.