Le vulnerabilità del software sono illimitate?

Puoi sbarazzarti di tutti i bug rimuovendo tutta la complessità del software finché si comporta l'hardware. Un esempio potrebbe essere un codice macchina che accende una luce quando viene premuto un pulsante.

I problemi iniziano quando cerchi di risolvere problemi più impegnativi, aggiungendo un utente che desidera molte funzionalità, ad esempio. La quantità di codice aumenta, è presto logico utilizzare linguaggi di programmazione di alto livello che potrebbero avere un comportamento strano o indefinito.

Più pulsanti aggiungi, più diventa complesso il codice e più bug si possono aspettare. Spendere più denaro per evitare o trovare questi bug potrebbe non trovarli mai tutti, anche per le organizzazioni .

Questa domanda include due parti: perché abbiamo così tanti bug in primo luogo e perché non tutti i bug vengono rilevati e risolti con un tempo sufficiente.

Perché abbiamo bug del software

La scrittura del software richiede risorse, cioè tempo, conoscenza degli sviluppatori e denaro. C'è sempre una mancanza di tempo (per andare al mercato) e il numero e l'esperienza degli sviluppatori. Inoltre, più sviluppatori non significa semplicemente che il prodotto viene svolto più velocemente perché più sviluppatori significano più sovraccarico di comunicazione che aumenta la complessità. E c'è una carenza di denaro, perché c'è la necessità che il prodotto abbia un ritorno positivo sull'investimento.

Quindi, per scrivere software più sicuro, in primo luogo dovresti mirare a una complessità minima che puoi gestire con il minor numero di sviluppatori possibile. Ma sfortunatamente le complesse esigenze dei clienti contraddicono spesso questo obiettivo. Oltre a questo, i requisiti cambiano con il tempo perché l'ambiente in cui il software viene utilizzato cambia.

In questo modo anche il software con un buon progetto iniziale sviluppato da sviluppatori esperti diventa più complesso nel tempo. E la maggior parte del software non è stata ancora sviluppata con un buon progetto iniziale da sviluppatori esperti, ma molti hanno appena iniziato come un prototipo che inizialmente ha funzionato abbastanza bene e poi è stato esteso ed esteso nel tempo spesso da diversi sviluppatori (con una comprensione limitata del progetto iniziale ).

E questa è solo una delle ragioni per cui hai dei bug. Altri motivi sono che il software viene utilizzato in un ambiente per il quale non è mai stato progettato, come il software progettato per un ambiente chiuso e protetto ora viene connesso a Internet aperto.

Perché non tutti i bug vengono trovati e risolti

Ricercatori e sviluppatori di sicurezza all'interno e all'esterno delle società di software hanno gli stessi limiti: c'è solo un numero limitato di tempo e un numero limitato di ricercatori, mentre c'è un sacco di software con potenziali problemi. Pertanto, i ricercatori di sicurezza si concentrano sul software che promette il più grande ritorno di investimento prima, cioè dove i bug ad alto impatto possono essere trovati nel minor tempo utilizzando la conoscenza specifica e l'esperienza del ricercatore.

Questo ovviamente lascia molti bug nascosti perché alcuni potrebbero aver bisogno di un'esperienza specifica, alcuni sembrano non valere la pena di essere rilevati o semplicemente perché non c'è tempo per esaminare l'area specifica del software. E anche se viene rilevato un errore, potrebbe non essere abbastanza critico investire risorse per risolverlo (alcune o solo così profondamente nella progettazione che è troppo costoso) o il produttore del software potrebbe non esistere più o il software è dichiarato fine vita quindi nessuno dovrebbe usarlo comunque (anche se molti lo fanno per vari motivi).

Non possiamo semplicemente ignorare gli errori non ancora trovati?

Trovare e sfruttare bug è simile all'estrazione di risorse naturali: ci sono ancora molte risorse non scoperte e ci sono luoghi in cui lo sfruttamento di queste risorse è troppo costoso. Ma nuove conoscenze, nuove tecniche o semplicemente un aumento del valore marcato di risorse specifiche rendono interessante sfruttare queste risorse o cercare altre risorse nascoste. In caso di bug questa potrebbe essere una nuova tecnica o uno strumento che rende facile trovare nuove classi di bug. In alternativa, il cambio di casi d'uso rende operativi vettori di attacco in precedenza impossibili, come la connessione di alcuni software a Internet. Oppure potrebbe esserci un obiettivo prezioso utilizzando un software specifico che lo rende interessante per cercare vulnerabilità in questo software e sfruttarlo.

Non sono tecnicamente senza limiti, ma nella pratica potrebbero anche essere illimitati. Il codice ben scritto e ben collaudato potrebbe essere in grado di far scendere il numero di bug fino a un solo bug per cento righe di codice. Windows XP ha 45 milioni di righe di codice. Quindi sarebbero 450.000 bug. Queste non saranno tutte vulnerabilità della sicurezza, ma anche se l'1% di esse fosse, non saremmo mai esaurite.

Non sono sicuro di poter effettivamente calcolare il numero esatto di possibili vulnerabilità o exploit in base al codice e al numero di righe. Ma il rischio di vulnerabilità sfruttabili e non sfruttabili aumenta con l'età del software e soprattutto quando diventa fuori dal ciclo di supporto del flusso principale. Se si pensa a cosa sia effettivamente una vulnerabilità e quanto complesso possa essere un intero sistema operativo o qualsiasi software, non è solo il codice sorgente stesso a essere vulnerabile; potrebbe esserci una combinazione di configurazione e codice che si aggiungono a quei numeri. Potrebbero esserci anche vulnerabilità non direttamente nel codice sorgente ma il modo in cui il software o il sistema operativo decide di eseguire o gestire i dati durante l'elaborazione.

Detto questo, puoi potenzialmente rilevare una serie di vulnerabilità riconoscibili basate su analisi dell'origine del codice statico utilizzando strumenti o tramite una media manuale. Per rispondere alla seconda parte della domanda, sì, è possibile che patch aggiuntive aprano nuove vulnerabilità. Dopo tutto, stai modificando e aggiungendo del codice, quindi un errore o un errore potrebbero creare nuovi problemi. Sebbene non sia un esempio esatto, un esempio è l'attacco denial of service. Le finestre aggiornate in quel momento potevano essere ancora suscettibili a molto vecchie Attacchi basati su LAND LAND in pila.

Con questo anche in mente, pensa agli 0 giorni che vengono rilasciati anche con tutti gli aggiornamenti e i ricercatori di sicurezza che divulgano vulnerabilità per l'applicazione di patch e la codifica sicura. Eterneblue era uno di questi esempi.

Volevo solo fare riferimento a questa ben nota citazione attribuita a Einstein:

Two things are infinite: the universe and human stupidity; and I’m not sure about th’universe!

Poiché i programmatori sono meri esseri umani, a volte fanno errori a causa della citazione sopra. Poiché i programmi sono ora sempre più complessi, rappresentano un numero enorme di linee di codice. Quindi ci sono bug in qualsiasi grande base di codice.

Naturalmente, molti di questi vengono trovati durante i test iniziali (prima che il codice venga mai rilasciato) e altri vengono trovati e rattoppati dopo il rilascio del codice. La cattiva notizia è che anche le patch possono contenere bug, o rompere qualche altra parte del codice, e vengono aggiunte costantemente nuove funzionalità sempre nuove che arrivano con il loro grande codice e nuovi bug.

Ho parlato di bug qui perché le vulnerabilità non sono molto diverse, e IMHO sono solo un caso speciale di bug: qualcosa che avrebbe dovuto essere meglio codificato.

TL / DR: i programmi piccoli e stabili possono essere ripuliti da qualsiasi errore o vulnerabilità con un po 'di lavoro, ma non possono esserlo un software enorme e in continua evoluzione come il sistema operativo.