Penso che gli impatti maggiori saranno sul lato delle pubbliche relazioni.

Sul lato positivo (dal punto di vista dei manutentori di OpenBSD), l'idea che l'FBI considerasse OpenBSD abbastanza importante, nel 2000, garantire l'inserimento di backdoor garantito dal denaro, è un sicuro inflater dell'ego. Questo da solo potrebbe essere un motivo per accuse pubbliche di backdoor, che esistano o meno. Inoltre, l'apparente immediata e completa divulgazione è un bel lavoro di PR.

Sul lato negativo, la comunicazione di OpenBSD è stata a lungo su quanto OpenBSD fosse molto più sicuro di qualsiasi altro sistema, grazie al controllo proattivo della sicurezza e numerosi revisioni del codice interno. Trovare una backdoor di dieci anni proprio nel mezzo del codice di rete crittografico ridurrebbe un po 'il mito.

Ora, dal lato tecnico ...

Ce ne sono molti modi in cui una sottile alterazione del codice potrebbe costituire una "backdoor". Se dovessi implementare io stesso una backdoor, proverei a truccare il generatore di numeri pseudo-casuali. È relativamente facile far sembrare che un PRNG produca output di qualità crittografica, ma con, in realtà, una bassa entropia interna (ad esempio 40 bit). Ciò renderebbe le comunicazioni protette da IPsec vulnerabili alla decrittografia con hardware comune e un attaccante solo passivo (quindi non rilevabile). Inoltre, un PRNG difettoso può essere attribuito all'incompetenza (perché realizzare un PRNG sbagliato è facile, ma crearne uno buono non lo è), aprendo la strada alla negabilità plausibile.

Un altro metodo di backdooring è la perdita di dati. Ad esempio, ogni volta che si hanno dei bit casuali in un pacchetto di rete, è possibile fare in modo che questi bit contengano effettivamente dati sullo stato del sistema interno. Una buona backdoor può quindi far trapelare chiavi di crittografia segrete, che devono essere raccolte da chiunque sia a conoscenza dell'esistenza della perdita.

I potenziali buffer overflow sono semplici backdoor, poiché possono essere sfruttati solo da aggressori attivi, il che è rischioso. Le agenzie di spionaggio di solito aborriscono i rischi. Se tali bug vengono rilevati nel codice OpenBSD, penso sia sicuro affermare che sono bug "veri", non buchi dannosi.

Come ho notato nel commento, questa è una domanda molto ampia. Esiste un'ampia varietà di potenziali ramificazioni. Una cosa è chiara però: Theo si è appena fatto un sacco di revisioni gratuite del codice ;-).

Forse l'FBI è riuscito a ottenere una backdoor nel codice IPSec di openbsd del 2001. Se lo hanno fatto, significa che ci sono state VPN su cui le forze dell'ordine statunitensi potrebbero curiosare. Ora se lo hanno fatto dipende dal fatto che qualcuno abbia implementato la VPN nella sua configurazione snoopable, se l'FBI abbia rilevato tale distribuzione e se gliene importasse.

Forse la backdoor è ancora lì. Tutto ciò significa che puoi aumentare il numero di installazioni a rischio. Soprattutto se qualsiasi altro sistema operativo prende il codice IPSec da OpenBSD ... FreeBSD, Mac OS X e iOS lo hanno fatto.

Ora, che la storia sia vera o meno, è interessante notare che nessuno compreso il responsabile del progetto OpenBSD può negarlo rapidamente. Questo, insieme alle backdoor di Linux che sono esistite nel tempo, mi ha portato a mettere in discussione la legge di Torvalds: molti occhi rendono i bug superficiali. Apparentemente è anche possibile nascondere le vulnerabilità in bella vista.

La risposta alla tua domanda è semplice: se qualcuno nascondeva codice dannoso in sottosistemi privilegiati, le persone sbagliate potrebbero avere un controllo arbitrario sui sistemi che eseguono il codice.

Ma nota che non è stata presentata alcuna prova Perry dovrebbe averne molte) e non si scusa.

Per maggiori informazioni vedere

• una prima panoramica: Deconstructing the OpenBSD IPsec Rumors (on obfuscurity.com)
• Theo de Raadt dubita che OpenBSD sia stato colpito, ma ritiene che NETSEC sia stato probabilmente incaricato di scrivere backdoor: 2010-12-21 Re: Allegations riguardanti OpenBSD IPSEC
• Ars Technica: L'audit del codice OpenBSD scopre bug, ma nessuna prova di backdoor

e gli umoristici commenti cospiratori sulle risposte dagli accusati: http://blog.scottlowe.org/2010/12/14/allegations-regarding-fbi-involvement-with-openbsd/ http://marc.info/ ? l = openbsd-tech&m = 129244045916861&w = 2

Questo non risponde davvero alla tua domanda, ma intorno al 2001 il codice potrebbe aver subito grandi cambiamenti nell'ultimo decennio, quindi è difficile dire se il codice sarebbe ancora lì (se fosse lì in primo luogo) .

Un po 'più vicino a una risposta utilizzabile: Graham ne ha elencati alcuni. La domanda successiva è quando hanno iniziato a consumare quel codice? Prima o dopo l'introduzione della potenziale backdoor? In seguito, è stata eseguita una revisione del codice da parte dell'azienda? Se è così, l'hanno trovato? In tal caso, l'hanno risolto? In tal caso, l'hanno fuso di nuovo nel progetto originale?

La prova migliore, per come l'ho letta, è che le accuse di una backdoor in OpenBSD sono così calde. Mi sembra una sbavatura scurrile e ingiustificata di OpenBSD, nel tentativo di diffondere FUD (paura, incertezza e dubbio).

A mio avviso, le accuse di Gregory Perry hanno poca credibilità a questo punto. Elencherò alcune delle prove contro le sue accuse:

• Perry non ha fornito prove verificabili a sostegno della sua accusa. Non ha risposto alle richieste di ulteriori informazioni.
• Le affermazioni nella lettera sono intrinsecamente poco credibili. Quale agenzia governativa gli darebbe un accordo di non divulgazione di 10 anni che gli permetta di parlare della backdoor dopo che sono passati 10 anni? Difficilmente plausibile.
• Un controllo del codice sorgente in corso di OpenBSD non ha trovato alcuna prova di una vulnerabilità a questo punto.
• La persona citata nella lettera di Perry nega categoricamente accuse. Come spiega, non aveva nemmeno accesso al codice crittografico, né ha scritto nessuno di quel codice. Altri sviluppatori OpenBSD si sono fatti avanti per garantire per lui.
• Il progetto software OpenBSD disponeva di misure di sicurezza per difendersi dall'introduzione di backdoor nel modo descritto da Gregory Perry, andando così lontano per garantire che tutto il codice crittografico per IPSEC sia scritto da cittadini non statunitensi.
• Ci sono buchi nella storia di Perry, in particolare, i tempi. Apparentemente Perry aveva lasciato NETSEC prima che le backdoor fossero apparentemente sviluppate, rendendo difficile capire come avrebbe acquisito conoscenza di eventuali backdoor se la sua storia fosse vera.

Penso sia possibile che NETSEC abbia condotto studi interni per esaminare come modificare OpenBSD per aggiungere una backdoor per il proprio uso interno, ma non c'è motivo di credere che una backdoor sia mai stata introdotta nella versione ufficiale Distribuzione di OpenBSD.

Conclusione: considero la lettera di Perry, che hai citato, una diffamazione infondata contro OpenBSD. OpenBSD è stato a lungo molto rispettato per la sua dedizione alla sicurezza. Ti suggerisco di trattare evitando di ridistribuire le accuse di Perry.

Divulgazione completa: non ho alcun legame con OpenBSD o con nessuna delle parti in questo piccolo scambio. Non ho alcun interesse finanziario in questa faccenda. Diamine, non eseguo nemmeno OpenBSD sui miei server. Odio vedere un buon prodotto sottoposto ad accuse infondate.