Domanda:
Il codice critico per la sicurezza deve essere riutilizzato o riscritto?
Hadrien G.
2014-11-07 16:04:29 UTC
view on stackexchange narkive permalink

Di solito, nella programmazione, riutilizzare il codice è sempre un'idea migliore che scrivere la propria implementazione di un algoritmo. Se un'implementazione è in circolazione da molto tempo ed è ancora utilizzata da molti progetti, è probabile che sia abbastanza ben progettata per cominciare, abbia ricevuto molti test e debug e forse la cosa più importante è qualcun altro responsabile del mantenimento ciò significa più tempo per concentrarsi sul prodotto software specifico che si sta realizzando.

Tuttavia, mi chiedevo se questo principio sia ancora vero per il codice critico per la sicurezza, che esegue attività come crittografia e autenticazione, o che viene eseguito con privilegi elevati per qualsiasi motivo. Se un'implementazione di un algoritmo è condivisa da molti sistemi software, allora c'è un forte incentivo per le persone a decifrarla e quando si trova un difetto, è probabile che sia un enorme disastro per la sicurezza. Heartbleed e Shellshock sono due esempi recenti che mi vengono in mente. E per gli esempi closed-source, scegli qualsiasi cosa da Adobe :)

Molti diversi pezzi di software che condividono una singola libreria critica per la sicurezza rendono anche questa libreria un obiettivo di scelta per gli aggressori che desiderano inserire una backdoor in essa. In un grande progetto open source con molte attività, è improbabile che venga notato un commit backdoor che presenta anche molte altre correzioni (come una pulizia dello stile del codice) come esca.

Con tutto questo in attenzione, il riutilizzo del codice è ancora considerato una buona pratica per il codice che esegue attività critiche per la sicurezza? E se sì, quali precauzioni dovrebbero essere prese per mitigare i suddetti punti deboli di tale approccio?

Non sarei d'accordo sul commit "backdoor" open source. In qualsiasi progetto open source ampiamente utilizzato, i manutentori sono molto bravi a controllare i commit prima che vengano effettivamente uniti e probabilmente non trascurerebbero qualcosa di così critico come l'inserimento di una backdoor. Suppongo che dipenda dalla complessità della backdoor (un buffer overflow potrebbe essere difficile da rilevare in C, ad esempio), ma in senso generale è * molto * probabile che venga notato, specialmente se ci sono molti contributori attivi al progetto. Ottima domanda comunque, +1!
@ChrisCirefice tranne quando le pratiche del codice sono mature per il backdooring come con heartbleed
Cinque risposte:
#1
+66
Thomas Pornin
2014-11-07 16:30:30 UTC
view on stackexchange narkive permalink

L'importante è la manutenzione . Indipendentemente dal fatto che tu abbia riutilizzato il codice esistente o ne abbia scritto uno tuo, otterrai una sicurezza decente solo se c'è qualcuno, da qualche parte, che comprende il codice ed è in grado di tenerlo a galla riguardo, ad esempio, l'evoluzione dei compilatori e delle piattaforme. Avere codice senza bug è la cosa migliore, ma in pratica devi fare affidamento sulla prossima cosa migliore, ovvero la pronta risoluzione dei bug (specialmente i bug che possono essere sfruttati per un utilizzo dannoso, noti anche come vulnerabilità ), all'interno un breve lasso di tempo.

Se scrivi il tuo codice, il lavoro di manutenzione dipende esattamente dalle tue spalle. E quel lavoro può richiedere molto tempo. Ad esempio, se si decide di scrivere e mantenere la propria libreria SSL / TLS e di utilizzarla in produzione, è necessario comprendere tutte le peculiarità dell'implementazione crittografica, in particolare la resistenza agli attacchi al canale laterale e è necessario tenere d'occhio gli attacchi e le contromisure pubblicati. Se hai le risorse per farlo, sia in termini di tempo che di competenza, allora bene! Ma il costo della manutenzione non deve essere sottovalutato. Riutilizzare una libreria esistente, in particolare una libreria open source ampiamente utilizzata, può essere molto più economico a lungo termine, poiché la manutenzione viene eseguita da altre persone e l'uso diffuso garantisce un controllo esterno. Come bonus, non puoi essere biasimato per le falle di sicurezza in una libreria esterna se metà del mondo le condivide.

Per riassumere, la questione non riguarda realmente il riutilizzo del codice , ma sul riutilizzo dello sforzo di manutenzione .

(Scrivo tutto questo indipendentemente dalle grandi qualità pedagogiche dello scrivere il tuo codice. Ti incoraggio a fare le tue implementazioni - ma certamente no per usarli effettivamente in produzione. Questo è per imparare .)

In realtà, tutte le risposte pubblicate finora sono ottime, ma preferisco questa in quanto è valida anche quando si ha l'esperienza interna necessaria per scrivere codice sicuro.
@HadrienG. Se utilizzi, ad es. OpenSSL, e hai anche esperti interni in grado di mantenerlo, considera la possibilità di farlo e contribuisci al progetto.
#2
+38
AviD
2014-11-07 16:31:07 UTC
view on stackexchange narkive permalink

Ancora di più.

Il codice di sicurezza è complicato . Il codice di crittografia è decisamente difficile , anche se sei un crittografo esperto, e impossibile da capire se non lo sei.

Se ci sono così tanti bug critici in così tanti pacchetti software e aziende importanti, cosa ti fa pensare * che saresti in grado di fare un lavoro migliore?

* A meno che, naturalmente, questo non sia il tuo ambito di competenza specifico e la funzionalità di sicurezza sia fondamentale per il tuo prodotto ...

#3
+15
Matija Nalis
2014-11-08 19:48:43 UTC
view on stackexchange narkive permalink

Domanda interessante! Vorrei rispondere più dal punto di vista della probabilità che dal punto di vista delle migliori pratiche correnti.

Sebbene Thomas e altri forniscano ottime risposte, non credo che tocchino la domanda principale, che è "è unica codice (o meno utilizzato) più resiliente nella pratica del codice popolare ". Tieni presente che non ho deliberatamente utilizzato "codice più sicuro del popolare". E a cosa si riduce il caso speciale di "la sicurezza attraverso l'oscurità funziona"?

E (e so che questa non sarà una risposta popolare) penso che quando sostituiamo "sicuro" con "resiliente" la risposta potrebbe non essere sempre comunemente accettata "mai!"

È evidente che probabilmente è meno sicuro (il che significa: è molto probabile che il tuo codice di sicurezza sia più facile / veloce da violare rispetto a quello popolare che ha subito molti attacchi prima e risolto da persone più intelligenti di te).

Tuttavia, a meno che tu non sia un sito grande / popolare, significa anche che sei molto meno interessante per i potenziali cracker se non possono riutilizzare il codice / gli sforzi spesi per crackarti, e questo sforzo non è banale (il che significa che il tuo sito non si interromperà a sonde di non convalida dei parametri / SQL injection automatizzate ). Questo ovviamente non funziona se sei mirato in modo specifico (spionaggio industriale ecc.), Ma la stragrande maggioranza degli attacchi di quei giorni sembra in realtà essere sonde automatizzate per software popolare.

Quindi, se la domanda non è "che è più sicuro", ma "che è meno probabile che venga violato", la risposta potrebbe effettivamente essere "dipende". Ecco alcuni esempi:

Esempio 1: immagina un computer Microsoft Windows 8.1 (o qualunque cosa sia popolare oggigiorno), senza falle di sicurezza note, acquistato ma mai aggiornato, connesso a Internet. Immagina anche Windows 3.11 vecchio di decenni con Winsock, mai patchato, con note centinaia di buchi di sicurezza, connesso a Internet. Entrambi vengono utilizzati nello stesso modo. Ignora ai fini della discussione sulla qualità dell'accesso ... La domanda è: quale sarà suddiviso prima?

Sebbene sia ovvio che 3.11 sia molto meno sicuro, non ci sono quasi exploit in circolazione che lo prendono di mira . Quindi potrebbe benissimo essere che ci sarebbe un exploit 0-day molto popolare per colpire 8.1, prima che 3.11 colpisca qualche exploit arcaico che riesca a eseguirlo.

Esempio 2: Immagina di avere l'ultima versione di Joomla CMS su un server web senza exploit attuali noti e script perl fatto a mano che eseguono cose CMS-ish, con bug sfruttabili noti (ma nessuno di loro sospetta per i test automatizzati attualmente disponibili). Dopo un anno, quali sono le probabilità che venga sfruttato?

Sebbene prove aneddotiche, in poche dozzine (a centinaia) di casi che ho avuto negli ultimi decenni, nella grande maggioranza dei casi è stata così popolare il software è stato sfruttato, mentre quelli obsoleti continuano a funzionare fino ad oggi indisturbati.

Altre cose da considerare:

  • se il software popolare esegue l'aggiornamento automatico (o gli amministratori lo aggiornano SEMPRE prontamente), quindi i punti deboli di questo codice popolare sono molto ridotti (ma non eliminati, a causa di exploit 0-day e non pubblicati) e quindi ha un grande vantaggio
  • al contrario, se il software non riceverà manutenzione, non popolare (come l'auto-scritto) potrebbe effettivamente essere meno sospetto di problemi
  • colpa: spesso potrebbe essere vantaggioso utilizzare software popolare. Se la metà del mondo è colpita, non sarai incolpato come se fossi un unico programmatore. Ciò è particolarmente importante se si lavora con i soldi. Spesso è "meglio" essere meno sicuri ma essere in grado di scaricare la colpa, piuttosto che essere più sicuri ma dover sostenere il costo da soli quando l'exploit colpisce.
  • funziona - già menzionato da altri, popolare il software nella stragrande maggioranza dei casi si aggiusta da solo, devi solo aggiornarlo, il che è molto meno faticoso che trovare e correggere i bug da solo (ma richiede comunque un po ' manutenzione)
  • un altro Il vantaggio per il software autoprodotto è spesso la riduzione del codice di massa (che porta a meno bug), poiché di solito non è necessaria la maggior parte delle funzionalità o della personalizzazione. Ad esempio, le persone useranno Joomla anche se tutto ciò di cui hanno bisogno è un semplice "sito di notizie modello" che potrebbe in pratica essere realizzato con poche dozzine di righe di codice. Anche se tu come programmatore non sei bravo la metà di quelli esperti che lavorano su un software popolare (quindi hai un numero notevolmente più alto di bug per riga di codice), spesso puoi comunque vincere con un ampio margine a causa dell'ordine di grandezza ( o pochi!) meno codice da scrivere / mantenere
Aw, ora vorrei poter contrassegnare due risposte come risposte, poiché anche questa interpretazione alternativa dell'argomento è estremamente interessante e ponderata :)
#4
+12
Lawtonfogle
2014-11-07 21:09:56 UTC
view on stackexchange narkive permalink

La risposta semplice è: non utilizzare la tua sicurezza.

Ci sono due parti in questo. Algoritmo e implementazione.

Per quanto riguarda l'algoritmo, creare il tuo algoritmo di crittografia è orrendo. Anche se sei esperto nel campo della crittografia, non sei ancora in grado di creare un nuovo algoritmo. A meno che tu non abbia un team di esperti nel campo che ci lavora, non esegui il tuo algoritmo. Per portare a casa questo punto, guarda alcuni dei recenti algoritmi che sono stati violati e come sono stati violati. Ciò che sembra fantastico al valore nominale ha punti deboli che non avrei mai concepito.

Per quanto riguarda l'implementazione, creare la tua implementazione di un buon algoritmo non è orribile come creare il tuo algoritmo, ma a meno che tu non sia un professionale, non farlo. Un errore nell'implementazione e non importa quanto fosse buono l'algoritmo di base. In questo caso, la domanda che devi porci è se sei migliore dei tanti esperti che hanno lavorato per mettere insieme una libreria di sicurezza di prima qualità.

Ciò che è più probabile. Che puoi eseguire il rollio del tuo algoritmo e della tua implementazione senza errori o punti deboli o che l'algoritmo e l'implementazione che usi avranno una backdoor?

Se potessi creare un algoritmo perfetto con l'implementazione, il rischio della backdoor non sarebbe un problema. Ma questo non è realistico.

C'è anche la domanda di cui vuoi spiegare al tuo manager / azionista / ect.? Che ci fosse una backdoor inserita in un pacchetto software affidabile di alto livello che ha coinvolto l'intero settore o che il tuo tentativo personale di migliorare la sicurezza è fallito orribilmente. Personalmente preferirei di gran lunga spiegare che ho fatto la scelta che hanno fatto i professionisti di tutto il settore e l'unico motivo per cui ha fallito è stato un problema di livello enorme che sta influenzando anche le multinazionali.

Detto questo, sono d'accordo con Thomas che provare a farlo da soli è una buona esperienza di apprendimento fintanto che non vede mai la luce della produzione.

#5
+2
Courtney Schwartz
2014-11-10 21:05:26 UTC
view on stackexchange narkive permalink

La sicurezza non è necessariamente migliorata semplicemente se il codice viene compilato con istruzioni leggermente diverse. La sicurezza è:

  1. Algoritmo
  2. Implementazione
  3. Controllo
  4. Manutenzione

Se non stai scrivendo algoritmi migliori e più sicuri - che potrebbero richiedere anni di ricerca - e non stai facendo controllare il tuo codice e applicare le patch di conseguenza, quindi è molto improbabile che un'implementazione leggermente diversa ti renda sicuro.

Heartbleed, Shellshock, BEAST, POODLE e altri ultimi importanti problemi SSL / TLS si sono verificati a causa di problemi inerenti al CRC e agli algoritmi autoreferenziali stessi e alla mancanza di controlli del codice esperti, non dovuti all'implementazione.

Se non capisci veramente come hanno fallito, decisamente non dovresti scrivere il tuo codice di sicurezza. Aggiungerai più problemi di quanti ne risolverai.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...