Qual è l'impatto potenziale del presunto attacco IPSEC di OpenBSD?

15

Recentemente c'è un po 'di preoccupazione per le backdoor di crittografia in IPsec e mentre lo stato di questo non è stato confermato, non so quale impatto qualcosa di simile potrebbe avere .

Ad esempio, questo significa che, dal momento che la crittografia su questo livello potrebbe essere compromessa, abbiamo vulnerabilità su varie piattaforme di tecnologia Internet (ad esempio, SSL)?

Che cosa permette una backdoor funzionante in termini di attacchi di Eve e Mallory?

    
posta Incognito 15.12.2010 - 16:25
fonte

5 risposte

14

Penso che l'impatto maggiore sarà sul lato delle relazioni pubbliche.

Sul lato positivo (dal punto di vista dei manutentori di OpenBSD), l'idea che l'FBI ritenesse abbastanza importante OpenBSD, già nel 2000, per giustificare l'inserimento di backdoor back-back, è un sicuro influsso dell'ego. Questo da solo potrebbe essere un motivo per le accuse pubbliche di backdoor, che esistano o meno. Inoltre, l'apparente divulgazione immediata e completa è un bel lavoro di pubbliche relazioni.

Dal lato negativo, le comunicazioni di OpenBSD riguardano da tempo la sicurezza di OpenBSD rispetto a qualsiasi altro sistema, grazie al controllo proattivo della sicurezza e numerose revisioni interne del codice. Trovare una backdoor di dieci anni proprio nel mezzo di un codice di rete crittografico avrebbe un po 'sgonfiato il mito un po'.

Ora, dal lato tecnico ...

Ci sono molti modi in cui una sottile alterazione del codice potrebbe costituire una "backdoor". Se dovessi implementare una backdoor io stesso, proverei a rigare il generatore di numeri pseudo-casuali. È relativamente facile far apparire a un PRNG un 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 decodifica con hardware comune e un attaccante passivo (quindi non rilevabile). Inoltre, un PRNG imperfetto può essere attribuito all'incompetenza (perché fare un cattivo PRNG è facile, ma farlo bene non è), aprendo la strada a negabilità plausibile .

Un altro metodo di backdooring è la perdita di dati. Ad esempio, ogni volta che si dispone di alcuni bit casuali in un pacchetto di rete, è possibile disporre che questi bit contengano effettivamente dati sullo stato interno del sistema. Una buona backdoor può quindi perdere chiavi segrete di crittografia, per essere rilevata da chiunque sia a conoscenza dell'esistenza della perdita.

Potenziali overflow del buffer sono backdoor grezze, dal momento che possono essere sfruttate solo da attaccanti attivi, il che è rischioso. Le agenzie di spionaggio di solito corrono il rischio. Se tali errori si trovano nel codice OpenBSD, penso che sia sicuro affermare che sono bug "veri", non buchi malevoli.

    
risposta data 15.12.2010 - 22:38
fonte
8

Come ho notato nel commento, questa è una domanda molto ampia. Ci sono una vasta gamma di potenziali ramificazioni. Una cosa è chiara però: Theo si è appena procurato un sacco di recensioni di codice libero; -).

Forse l'FBI è riuscito a ottenere una backdoor nel codice IPSec openbsd dell'era del 2001. Se lo facessero, vuol dire che ci sono state delle VPN che le forze dell'ordine americane potrebbero spiare. Ora, se ha dipende da se qualcuno ha implementato la VPN nella sua configurazione snoopable, se l'FBI ha rilevato tale distribuzione e se ne è interessato.

Forse la backdoor è ancora lì. Tutto ciò significa che è possibile aumentare il conteggio delle installazioni a rischio. Soprattutto se altri sistemi operativi hanno preso il loro codice IPSec da OpenBSD ... FreeBSD, Mac OS X e iOS lo hanno fatto tutti.

Ora, indipendentemente dal fatto che la storia sia vera o meno, è interessante notare che nessuno, compreso il lead 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 gli insetti superficiali. Apparentemente è possibile nascondere le vulnerabilità anche in bella vista.

    
risposta data 15.12.2010 - 18:22
fonte
5

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

Notate che non sono state presentate prove (e Perry dovrebbe averne molte), e non offre scuse.

Per maggiori informazioni vedi

e gli umoristici commenti cospiratori sulle risposte degli accusati:   link   link

    
risposta data 16.12.2010 - 22:06
fonte
2

Questo in realtà non risponde alla tua domanda, ma il codice del 2001 potrebbe aver avuto importanti cambiamenti nell'ultimo decennio, quindi è difficile dire se il codice sarebbe comunque presente (se fosse lì in primo luogo) .

Un po 'più vicino a una risposta utilizzabile: Graham ne ha elencati alcuni. La prossima domanda è quando hanno iniziato a consumare quel codice? Prima o dopo l'introduzione della potenziale backdoor? Se dopo, c'era una revisione del codice fatta dall'azienda? Se è così, l'hanno trovato? Se è così, l'hanno risolto? In tal caso, l'hanno unificato nel progetto originale?

    
risposta data 15.12.2010 - 19:43
fonte
2

La migliore prova, come ho letto, è che le accuse di una backdoor in OpenBSD sono talmente 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 affermazione. Non ha risposto alle richieste di ulteriori informazioni.
  • Le affermazioni nella lettera sono intrinsecamente poco credibili. Quale agenzia governativa gli avrebbe dato una NDA a 10 anni che gli permettesse di parlare della backdoor dopo 10 anni di passata? Difficilmente plausibile.
  • Un controllo del codice sorgente in corso su OpenBSD non ha rilevato alcuna evidenza di vulnerabilità a questo punto.
  • La persona che viene chiamata nella lettera di Perry nega categoricamente le accuse . Come spiega, non ha nemmeno avuto accesso al codice crittografico, né ha scritto alcun codice. Altri sviluppatori di OpenBSD hanno intensificato l'accesso a per garantire .
  • Il progetto software OpenBSD aveva delle protezioni per difendersi dall'introduzione delle backdoor nel modo in cui Gregory Perry descrive, arrivando a assicurati che tutto il codice crittografico per IPSEC sia scritto da cittadini non statunitensi .
  • Ci sono buchi nella storia di Perry, in particolare, i tempi. A quanto pare Perry aveva lasciato NETSEC prima che le backdoor fossero apparentemente sviluppate , rendendo difficile capire come avrebbe acquisito la conoscenza di qualsiasi backdoor se la sua storia fosse vera.

Penso sia possibile che NETSEC abbia condotto studi interni per esaminare come modificare OpenBSD in aggiungi una backdoor per il loro uso interno , ma non c'è motivo di credere che qualsiasi backdoor sia mai stata introdotta nella distribuzione ufficiale di OpenBSD.

Conclusione: considero la lettera di Perry, che lei ha citato, una macchia infondata contro OpenBSD. OpenBSD è stato a lungo altamente rispettato per la sua dedizione alla sicurezza. Ti suggerisco di evitare di ridistribuire le accuse di Perry.

Completa divulgazione: non ho alcuna associazione con OpenBSD o nessuna delle parti in questo piccolo scambio. Non ho alcun interesse finanziario in questa materia. Diamine, non ho nemmeno eseguito OpenBSD sui miei server. Odio solo vedere un buon prodotto sottoposto a accuse infondate.

    
risposta data 17.01.2011 - 05:34
fonte

Leggi altre domande sui tag