EMB_64

69 / 84

69
EMBEDDED 64 • MAGGIO • 2017
DYNAMIC ANALYSIS | SOFTWARE
ti dell’analisi statica, solitamente basati su regole
e gestiti tardivamente nel ciclo di sviluppo, quando
vengono usati da soli possono creare potenziali falsi
positivi, ovvero nascondendo l’errore reale sotto un
' 2 . À' N
Web-server Open Source che alimenta parte di Wi-
kipedia(4), abbiamo un esempio di codice che con-
tiene una vulnerabilità del puntatore NULL poten-
zialmente sfruttabile. Mentre uno delle variabili di
ingresso viene controllata se è NULL, l’altra viene
44 4 À 2 . -
muni strumenti di analisi statica Open Source, que-
sto problema è stato ignorato, mentre l’analizzatore
commerciale Lintlo ha rilevato ma solo come un pos-
sibile errore. Tuttavia, utilizzando uno strumento di
analisi dinamica, è stata immediatamente trovata
la violazione Segmentation Fault che, se non corret-
ta, avrebbe potuto essere sfruttata portando ad un
indesiderato impatto funzionale(5). L’analisi dina-
mica abbinata all’analisi statica può dare un imme-
diato ritorno. L’analisi dinamica del programma è
diversa dato che è attuata mediante l’esecuzione di
programmi su una architettura del processore, vera
e propria o simulata. Questo modalità di analisi del
software sottopone il programma ad un numero di
À 4
reali ed eccezionali, così il suo comportamento può
essere osservato e testato per le sue falle nella sicu-
rezza. Esiste un elenco formale, sviluppato dalla co-
munità e che gode di alta considerazione, nota come
“Common Weakness Enumeration” (CWE) che ser-
ve come linguaggio comune per la descrizione dei
punti deboli della sicurezza software, nell’architet-
tura e nel codice, ed è un lessico comune, standard,
per gli strumenti di rilevazione di tali potenziali
punti deboli. Nella tassonomia CWE, ci sono nume-
rosi punti deboli dove l’uso di prove dinamiche può
evidenziare le vulnerabilità, in particolare qualsiasi
cosa manifesti errori gravi come l’uso di puntatori
NULL, Buffer Over- oUnder-Runs, e Stack Over-
Á [2 . À' % 7 4
rilevato nel codice di uno dei nostri clienti del setto-
re Automotive. Nel codice in questione, sono stati
effettuati i vari controlli nei confronti di una varia-
bile, che è stata poi ancora utilizzata nel denomina-
tore di un’espressione matematica. Anche in questo
caso, lasciata così senza controllo, questa debolezza
potrebbe avere un impatto reale sul business dell’a-
zienda. Mentre gli strumenti statici possono solo
dare un suggerimento sulla potenziale esistenza di
tali errori, con l’analisi dinamica possiamo costruire
un test e dimostrare immediatamente la vulnerabi-
lità. Ogni team di sviluppo ha bisogno di un proces-
so per raggiungere i propri obiettivi di sicurezza per
le applicazioni. Credo che gli sviluppatori abbiano
bisogno di prendere in considerazione il fatto che
ci sono tre fasi per la creazione di un sistema che
gestisca il rilevamento delle vulnerabilità. In primo
luogo, costruire un portfolio completo di tutti i com-
ponenti / moduli nell’applicazione incluso qualsiasi
codice precedente e di terze parti ed assumerlo come
riferimento per evidenziare cosa è stato testato e
cosa deve essere fatto. In secondo luogo, una volta
che i dati siano stati raccolti gli sviluppatori han-
no bisogno di visibilità su eventuali vulnerabilità
nell’applicazione attraverso l’esecuzione dell’analisi
statica e dinamica. Ciò permetterà quindi agli svi-
luppatori di comprendere i rischi presenti nell’ap-
4 2 $ À & ' -
patori possono decidere di aumentare la quantità
di copertura del codice, dando visibilità alla qualità
del loro software. Il vantaggio di tutto questo lavoro
sta nel fatto che l’applicazione sarà di facile manu-
4 À -
no essere rianalizzate nel minor tempo possibile.
In conclusione, per i team di sviluppo è importante
comprendere che nessun singolo strumento si adat-
ta ad ogni circostanza, e che l’approccio più prag-
matico è quello di utilizzare più strumenti. L’analisi
statica ha il suo ruolo, ma l’esecuzione dinamica può
trovare alcune vulnerabilità con maggiore certezza
e, insieme, creeranno un prodotto più sicuro.
Note
1.
Metricon-2-Lee-Chess-Enterprise-Metrics.ppt
2.
3.
4.
lighttpd/
5. CWE-476 -: NULL Pointer Dereference
Fig. 2 – Esempio di un altro errore, evidenziato
nella ”Analytics Dashboard” di VectorCAST