Rivelare vulnerabilità nascoste nei componenti software

Oggi, lo sviluppo software spesso implica l'uso di Componenti o librerie create da altri. Questi componenti sono conservati in luoghi centrali, rendendoli accessibili agli sviluppatori. Tuttavia, utilizzare questi componenti può esporre il software a vari problemi, comprese Vulnerabilità, questioni di licenza e bug. Di conseguenza, capire questi componenti è fondamentale, e sono stati creati strumenti per aiutare ad analizzare quali Dipendenze software vengono utilizzate.

Una delle principali preoccupazioni riguarda le dipendenze nascoste che potrebbero sorgere quando il codice è duplicato o modificato. Questo è noto come cloning, dove il codice viene copiato direttamente, o shading, dove il codice viene spostato in spazi dei nomi diversi. Entrambe queste pratiche possono rendere difficile identificare difetti di sicurezza.

Questo articolo discute un nuovo metodo per individuare copie vulnerabili di codice in un repository popolare. Questo metodo è semplice perché non necessita di configurazioni complicate o database speciali. Invece, parte da vulnerabilità note ed esamina un ampio numero di campioni di codice per trovare copie potenzialmente vulnerabili. I risultati mostrano che molti strumenti esistenti spesso trascurano questi rischi nascosti.

#Importanza dei Componenti Software

Lo sviluppo software moderno si affida sempre di più a librerie e componenti. Questo consente agli sviluppatori di risparmiare tempo e fatica riutilizzando codice esistente anziché scrivere tutto da zero. Tuttavia, questo approccio crea anche sfide. Le vulnerabilità possono propagarsi attraverso questi componenti se non vengono mantenuti aggiornati. Eventi come la violazione dei dati di Equifax e lo sfruttamento di Log4Shell evidenziano quanto possano essere gravi questi problemi quando gli sviluppatori utilizzano componenti obsoleti o vulnerabili.

Un altro problema è che non tutto il codice è facilmente visibile nelle configurazioni di build. Questo significa che alcune vulnerabilità possono passare inosservate. Sono disponibili strumenti per scansionare e analizzare le dipendenze per identificare potenziali vulnerabilità. Questi strumenti controllano le vulnerabilità note elencate in database pubblici e notificano agli sviluppatori quando è necessario effettuare aggiornamenti.

#Panoramica degli Strumenti di Rilevamento delle Vulnerabilità

Gli strumenti di analisi della composizione software (SCA) sono progettati per aiutare gli sviluppatori a capire le loro dipendenze. Di solito, consistono in due parti principali: scansionare le dipendenze e verificarle rispetto ai database delle vulnerabilità conosciute. Ogni strumento ha il proprio modo di abbinare e identificare queste dipendenze, portando a possibili errori.

Sebbene questi strumenti siano utili, non sono perfetti. Possono perdere vulnerabilità, specialmente se il software scopre dinamicamente i componenti durante l'esecuzione o se il codice è stato copiato o nascosto. Possono sorgere problemi quando gli sviluppatori copiano senza saperlo codice da fonti inaffidabili o quando le librerie utilizzate da altre librerie creano situazioni complesse.

#Sfide con Cloning e Shading

Il cloning può verificarsi quando gli sviluppatori copiano il codice direttamente nei propri progetti, il che può introdurre vulnerabilità nascoste dal processo di copia. Queste vulnerabilità possono essere difficili da individuare, specialmente poiché il codice copiato potrebbe non somigliare all'originale.

Lo shading è un'altra pratica in cui interi pacchetti vengono rinominati. Questo può avvenire durante il processo di build, rendendo più difficile per gli strumenti trovare e analizzare le vulnerabilità. Sebbene lo shading possa essere vantaggioso, rendendo il codice più piccolo e possibilmente più sicuro rimuovendo funzionalità superflue, crea anche zone cieche per gli strumenti SCA che tracciano le dipendenze.

In Java, un problema comune simile a quello noto come "DLL hell" può verificarsi quando diverse versioni della stessa libreria entrano in conflitto. Questo porta spesso a errori che si manifestano solo quando il software è in esecuzione, causando ulteriori complicazioni.

#Rilevamento di Codice Vulnerabile

Per affrontare questi problemi, è stato sviluppato un nuovo approccio per analizzare i componenti Java. Questo metodo si concentra sulla ricerca di codice clonato nel popolare repository Maven senza necessità di un database personalizzato. Partendo da un insieme di vulnerabilità conosciute, il metodo recupera un numero elevato di potenziali clone dal repository e li analizza per vulnerabilità.

Dopo aver esaminato migliaia di componenti, è stata trovata una significativa quantità di clone vulnerabili confermati. Purtroppo, molti strumenti SCA esistenti hanno trascurato queste vulnerabilità. I risultati hanno portato a aggiornamenti nel Database di Sicurezza di GitHub, sottolineando la necessità di strumenti migliori in questo ambito.

#L'Esperimento

Per esplorare quanto spesso si verifichi lo shading, è stato condotto uno studio per esaminare i file Maven di GitHub. I risultati iniziali hanno indicato che una piccola percentuale di quei file usava il plugin Maven shade per lo shading, rivelando che le pratiche di shading non sono rare.

Lo studio mirava anche a rispondere a domande fondamentali su quanto fosse diffuso lo shading non tracciato e quali rischi comportasse. Queste informazioni erano importanti per valutare l'efficacia degli attuali strumenti di rilevamento delle vulnerabilità.

#Rilevamento di Zone Cieche

Per rilevare queste vulnerabilità nascoste in modo efficace, è stato creato un pipeline di elaborazione. Questa pipeline prende un artefatto vulnerabile noto e una vulnerabilità come input, analizzando la potenziale presenza della vulnerabilità nell'artefatto fornito.

Il design di questo strumento si concentra sull'accuratezza e sulla leggerezza. Non richiede di mantenere un indice separato, rendendolo più efficiente. La metodologia prevede l'estrazione delle firme delle classi per identificare potenziali clone e verificare la loro presenza attraverso test progettati per controllare le vulnerabilità in quei clone.

L'obiettivo è dimostrare che anche con strumenti semplici, è possibile rilevare più artefatti vulnerabili, sottolineando la necessità di superare le limitazioni degli strumenti SCA esistenti che lavorano principalmente con i metadati.

#Metodologia per il Rilevamento

Nella pipeline di rilevamento, sono coinvolti diversi passaggi:

1. Recupero di Binaries e Fonti: Lo strumento recupera il codice binario e sorgente dell'artefatto fornito per analizzarlo.
2. Selezione delle Classi: Estrae i nomi delle classi dall'artefatto, che vengono utilizzati per interrogare il repository alla ricerca di potenziali clone.
3. Recupero delle Corrispondenze delle Classi: Lo strumento interroga il repository per trovare altri artefatti che contengono classi con nomi corrispondenti, consolidando queste corrispondenze per trovare clone probabili.
4. Esecuzione dell'Analisi dei Clone: La pipeline esegue un'analisi per rilevare clone confrontando le strutture delle classi identificate.
5. Verifica delle Vulnerabilità: Vengono eseguiti test sui clone per confermare se la vulnerabilità nota è presente.

Questo approccio strutturato consente di identificare clone vulnerabili in un lasso di tempo ragionevole, enfatizzando il potenziale per un miglior rilevamento delle vulnerabilità precedentemente trascurate.

#Valutazione dei Risultati

Gli esperimenti condotti hanno rivelato un totale di 727 artefatti vulnerabili confermati tra varie vulnerabilità. Dopo aver perfezionato i risultati per rimuovere i duplicati e concentrandosi su istanze uniche, il numero delle scoperte è diminuito significativamente, indicando che molti clone vulnerabili erano effettivamente presenti.

Le vulnerabilità più comunemente rilevate nell'analisi riguardavano librerie spesso utilizzate nel processamento JSON. È interessante notare che molte di queste sono state trovate a impiegare tecniche di shading che ostacolano una facile individuazione.

Sebbene diversi strumenti SCA siano stati testati sui componenti originali, le loro prestazioni variavano. Alcuni strumenti sono stati in grado di identificare la maggior parte delle vulnerabilità, ma molti non sono riusciti a rilevare problemi nei componenti clonati. Una mera frazione dei clone testati è stata riconosciuta da questi strumenti, evidenziando un sostanziale divario in ciò che gli attuali strumenti SCA possono analizzare efficacemente.

#Limiti dello Studio

Sebbene l'analisi puntasse alla precisione, ci sono stati limiti. I test potrebbero non sempre riflettere l'intero ambito delle vulnerabilità, poiché alcune segnalazioni sono poco chiare o vaghe. Alcuni elementi, come la connettività di rete, non sono stati inclusi nei test per mantenerli rapidi ed efficienti.

Inoltre, l'analisi non è stata in grado di rilevare tutti i clone, specialmente quelli che coinvolgevano livelli più profondi di modifica del codice o cambiamenti personalizzati oltre la semplice rinominazione. Lo studio ha riconosciuto che trovare ogni artefatto vulnerabile non è fattibile, ma l'approccio dimostra che esiste un problema significativo che necessita di attenzione.

La dipendenza dal codice sorgente limita anche il rilevamento ai componenti basati su Java, escludendo altri linguaggi che possono compilare in bytecode Java.

#Conclusione

I risultati di questo studio indicano che i metodi esistenti per rilevare vulnerabilità nei componenti software necessitano di miglioramenti. Le questioni di cloning e shading portano a vulnerabilità nascoste che non sono attualmente affrontate da molti strumenti disponibili oggi.

La ricerca supporta l'idea che gli strumenti SCA dovrebbero includere meccanismi di analisi più approfonditi che tengano conto di più di semplici metadati di progetto. Con molte vulnerabilità ancora scoperte a causa di queste pratiche, c'è un'urgenza di tecniche di rilevamento migliorate per garantire la sicurezza del software.

Le evidenze mostrano che affrontare queste zone cieche può migliorare significativamente il rilevamento delle vulnerabilità, portando a pratiche di sviluppo software più sicure.