Affrontare le vulnerabilità nel software BusyBox
Investigando tecniche per migliorare la sicurezza di BusyBox usato nei dispositivi IoT.
― 8 leggere min
Indice
- La Necessità di Migliore Rilevazione di Bug
- L'Importanza del Fuzz Testing
- Utilizzare Grandi Modelli Linguistici (LLMS) per la Generazione di Semi
- Riutilizzo dei Dati di Crash
- Crescente Preoccupazione per la Cybersecurity
- Domande di Ricerca
- Fuzz Testing e le Sue Varianti
- Obiettivi della Ricerca
- Impostazione dell'Esperimento
- Risultati
- Utilizzo degli LLM per Generare Semi
- Tecnica di Riutilizzo dei Crash
- Analisi Manuale dei Crash
- Le Implicazioni più Ampie dei Risultati
- Lavoro Futuro
- Conclusione
- Fonte originale
- Link di riferimento
BusyBox è uno strumento software popolare che combina più di 300 comandi essenziali di Linux in un unico file eseguibile. È ampiamente usato in molti dispositivi che girano su Linux, soprattutto quelli con risorse limitate, come i dispositivi per l'Internet delle Cose (IoT). Proprio per il suo utilizzo in questi dispositivi, è fondamentale trovare e risolvere le Vulnerabilità in BusyBox.
Le vulnerabilità in BusyBox possono portare a seri problemi di sicurezza. Ad esempio, se una vulnerabilità consente l'esecuzione di codice remoto, un attaccante potrebbe prendere il controllo di un dispositivo. Purtroppo, molti dispositivi utilizzano ancora versioni obsolete di BusyBox che hanno vulnerabilità note. Questo solleva preoccupazioni significative per la sicurezza di dispositivi come router, telecamere e altre attrezzature di rete.
La Necessità di Migliore Rilevazione di Bug
Il numero di dispositivi IoT sta crescendo rapidamente e, con esso, il potenziale per le minacce alla sicurezza. Il firmware, cioè il software che controlla un dispositivo, spesso è composto da diversi componenti. Alcuni di questi componenti sono pacchetti software di terze parti, come BusyBox. Un difetto in una parte può influenzare molti dispositivi, quindi è cruciale controllare continuamente questi componenti per vulnerabilità.
Ci sono diversi tipi di firmware. Ad esempio, alcuni girano su sistemi operativi standard come Linux, mentre altri funzionano su sistemi operativi in tempo reale o non hanno affatto un sistema operativo formale. Tra questi tipi, il firmware basato su Linux è il più comune. Questo tipo di firmware utilizza spesso software applicativi come BusyBox, portando a molti possibili punti di attacco.
Fuzz Testing
L'Importanza delIl fuzz testing è una tecnica usata per identificare vulnerabilità nel software. Funziona immettendo dati casuali o inaspettati nel programma e cercando crash o comportamenti strani. Quando un programma va in crash, potrebbe indicare una vulnerabilità.
In questo studio, ci siamo concentrati sul migliorare il fuzz testing per BusyBox. Abbiamo sviluppato due tecniche principali per aiutare a trovare vulnerabilità in modo più efficace.
LLMS) per la Generazione di Semi
Utilizzare Grandi Modelli Linguistici (La prima tecnica che abbiamo introdotto è l'uso di Grandi Modelli Linguistici (LLMs) per generare semi di input iniziali per il fuzz testing. Questi modelli possono produrre dati di alta qualità basati su schemi nel codice, il che può portare a risultati di testing migliori.
Nei nostri esperimenti, abbiamo scoperto che l'uso di semi generati da LLM ha portato a un notevole aumento dei crash rilevati durante il fuzz testing. Questo dimostra che gli LLM possono essere molto utili per capire quale tipo di input potrebbe causare problemi nel software.
Sfruttando i modelli linguistici, possiamo automatizzare il processo di creazione di semi iniziali, risparmiando tempo e aumentando l'efficacia del processo di testing. Prima di questo approccio, generare dati di input di qualità era spesso un compito lento e laborioso per i tester.
Riutilizzo dei Dati di Crash
La seconda tecnica che abbiamo usato riguarda il prendere dati di crash da versioni più vecchie di BusyBox e applicarli a versioni più recenti. Questo approccio ci aiuta a identificare se vulnerabilità precedentemente rilevate esistono ancora nel software aggiornato. Riutilizzando i dati di crash, possiamo valutare rapidamente se una nuova versione di un programma ha problemi simili senza partire da zero con il fuzzing.
Questa tecnica rende il nostro processo di testing molto più efficiente. Invece di passare ore a eseguire test su versioni più recenti, possiamo partire da una raccolta di problemi noti e vedere se causano problemi nel nuovo software. Questo metodo è particolarmente utile per i prodotti con vincoli di tempo.
Crescente Preoccupazione per la Cybersecurity
L'aumento dei dispositivi connessi ha portato a preoccupazioni crescenti sulla cybersecurity. Dispositivi embedded come telecamere, termostati intelligenti e router sono spesso nel mirino degli attaccanti in cerca di sfruttare debolezze nel loro software.
Versioni più vecchie di componenti software, come BusyBox, si trovano comunemente in molti prodotti. La nostra ricerca ha scoperto una vasta gamma di versioni più vecchie di BusyBox ancora in uso, molte delle quali contengono vulnerabilità note. Questo sottolinea l'importanza di aggiornare i sistemi per proteggersi dalle minacce emergenti.
Domande di Ricerca
Durante il nostro progetto, abbiamo cercato di rispondere alle seguenti domande:
- Quanto sono diffuse le versioni più vecchie di BusyBox e come possiamo trovare rapidamente vulnerabilità in queste versioni?
- Come possiamo utilizzare il potere degli LLM per migliorare il fuzz testing per il software embedded?
Fuzz Testing e le Sue Varianti
Il fuzz testing può assumere forme diverse. Nel black-box fuzzing, il tester non conosce il funzionamento interno del software. Al contrario, il white-box fuzzing prevede l'accesso completo al codice del programma, consentendo un approccio più approfondito con tecniche come l'analisi di taint.
Il grey-box fuzzing è una via di mezzo. Combina elementi di entrambi gli approcci, utilizzando conoscenze parziali dello stato interno del programma. Il nostro progetto ha principalmente utilizzato il grey-box fuzzing con uno strumento chiamato AFL++, progettato per tracciare come l'input influisce sul codice durante l'esecuzione.
Obiettivi della Ricerca
I nostri principali obiettivi erano dimostrare il potenziale dell'uso degli LLM nel fuzz testing e utilizzare in modo efficace i dati di crash delle versioni più vecchie di BusyBox per valutare quelle più recenti.
Conducendo fuzz testing su vari componenti di BusyBox utilizzando le tecniche proposte, miravamo a identificare vulnerabilità e comprendere meglio come questi componenti potessero essere sfruttati.
Impostazione dell'Esperimento
Abbiamo iniziato i test reperendo i binari di BusyBox da prodotti embedded nel mondo reale. Questi binari sono stati raccolti utilizzando un dataset proprietario che conteneva vari campioni software.
Il testing stesso ha coinvolto due fasi principali:
- Utilizzo degli LLM per la generazione di semi iniziali: Abbiamo generato semi per il fuzz testing utilizzando GPT-4, un potente LLM.
- Applicazione della tecnica di riutilizzo dei crash: Abbiamo utilizzato dati di crash da versioni più vecchie di BusyBox per testare l'ultima versione e cercare vulnerabilità.
Risultati
Utilizzo degli LLM per Generare Semi
I nostri test hanno mostrato un chiaro aumento nel numero di crash rilevati quando si utilizzavano semi generati da LLM rispetto ai semi casuali. Questo ha dimostrato che gli LLM possono fornire input più pertinenti ed efficaci per il fuzz testing.
I risultati indicano che possiamo migliorare significativamente gli esiti del fuzzing semplicemente utilizzando input iniziali migliori, portando così a un esame più approfondito del comportamento del software.
Tecnica di Riutilizzo dei Crash
Applicando la nostra tecnica di riutilizzo dei crash all'ultima versione di BusyBox, abbiamo identificato numerosi crash senza dover condurre un ampio fuzz testing. Da un gran numero di crash raccolti da versioni più vecchie, un numero sostanziale ha causato errori nella versione più recente.
Questa scoperta evidenzia l'efficacia del riutilizzo dei crash nel scoprire rapidamente vulnerabilità in nuove versioni software con meno risorse.
Analisi Manuale dei Crash
Dopo aver completato i nostri test, ci siamo dedicati all'analisi manuale dei crash che abbiamo scoperto. Questo processo ha coinvolto la categorizzazione dei crash e la determinazione delle cause principali. Abbiamo usato strumenti come GDB per il debugging e Ghidra per l'ingegneria inversa.
Durante l'analisi, abbiamo scoperto che diversi crash erano legati a problemi all'interno della libreria GLIBC, un componente essenziale di cui BusyBox si avvale. Questi problemi assomigliavano a vulnerabilità precedentemente segnalate, il che indica la natura persistente di tali bug anche quando il software viene aggiornato.
Le Implicazioni più Ampie dei Risultati
La nostra ricerca non solo ha scoperto vulnerabilità specifiche in BusyBox, ma ha anche evidenziato l'importanza di un'attenzione continua ai componenti software embedded. La presenza di versioni software obsolete comporta rischi che possono compromettere la sicurezza dei dispositivi.
Implementando le tecniche proposte, sviluppatori e professionisti della sicurezza possono rilevare vulnerabilità in modo più efficiente, rafforzando così la cybersecurity complessiva.
Lavoro Futuro
Questa ricerca apre nuove aree per ulteriori esplorazioni. Ci sono molte applicazioni potenziali sia per gli LLM che per le tecniche di riutilizzo dei crash nel testing di altri componenti software, specialmente all'interno di sistemi embedded.
Studi futuri potrebbero concentrarsi sulla creazione di LLM addestrati specificamente per formati di input unici in diversi protocolli. Questo potrebbe migliorare notevolmente l'efficacia del fuzz testing su dispositivi che utilizzano standard meno comuni.
Inoltre, la tecnica di riutilizzo dei crash può essere adattata per un'ampia gamma di componenti software, consentendo valutazioni di sicurezza più robuste su varie piattaforme e dispositivi.
Conclusione
La nostra indagine su BusyBox ha mostrato un notevole potenziale nel migliorare le metodologie di testing del software. Sfruttando gli LLM per generare semi di input iniziali e riutilizzando i dati di crash delle versioni più vecchie, possiamo identificare in modo efficace vulnerabilità in molti dispositivi che girano su software obsoleto.
Le crescenti preoccupazioni per la cybersecurity enfatizzano la necessità di un continuo miglioramento nel modo in cui testiamo e mettiamo in sicurezza i dispositivi embedded. I nostri risultati avvertono per una maggiore consapevolezza e azione nell'affrontare le sfide di sicurezza poste dai componenti software obsoleti.
In sintesi, questa ricerca sottolinea sia l'efficacia delle nuove tecniche nel fuzz testing sia l'importanza di tenere il software aggiornato per prevenire sfruttamenti.
Titolo: Fuzzing BusyBox: Leveraging LLM and Crash Reuse for Embedded Bug Unearthing
Estratto: BusyBox, an open-source software bundling over 300 essential Linux commands into a single executable, is ubiquitous in Linux-based embedded devices. Vulnerabilities in BusyBox can have far-reaching consequences, affecting a wide array of devices. This research, driven by the extensive use of BusyBox, delved into its analysis. The study revealed the prevalence of older BusyBox versions in real-world embedded products, prompting us to conduct fuzz testing on BusyBox. Fuzzing, a pivotal software testing method, aims to induce crashes that are subsequently scrutinized to uncover vulnerabilities. Within this study, we introduce two techniques to fortify software testing. The first technique enhances fuzzing by leveraging Large Language Models (LLM) to generate target-specific initial seeds. Our study showed a substantial increase in crashes when using LLM-generated initial seeds, highlighting the potential of LLM to efficiently tackle the typically labor-intensive task of generating target-specific initial seeds. The second technique involves repurposing previously acquired crash data from similar fuzzed targets before initiating fuzzing on a new target. This approach streamlines the time-consuming fuzz testing process by providing crash data directly to the new target before commencing fuzzing. We successfully identified crashes in the latest BusyBox target without conducting traditional fuzzing, emphasizing the effectiveness of LLM and crash reuse techniques in enhancing software testing and improving vulnerability detection in embedded systems. Additionally, manual triaging was performed to identify the nature of crashes in the latest BusyBox.
Autori: Asmita, Yaroslav Oliinyk, Michael Scott, Ryan Tsang, Chongzhou Fang, Houman Homayoun
Ultimo aggiornamento: 2024-03-06 00:00:00
Lingua: English
URL di origine: https://arxiv.org/abs/2403.03897
Fonte PDF: https://arxiv.org/pdf/2403.03897
Licenza: https://creativecommons.org/licenses/by/4.0/
Modifiche: Questa sintesi è stata creata con l'assistenza di AI e potrebbe presentare delle imprecisioni. Per informazioni accurate, consultare i documenti originali collegati qui.
Si ringrazia arxiv per l'utilizzo della sua interoperabilità ad accesso aperto.
Link di riferimento
- https://www.ndss-symposium.org/wp-content/uploads/2017/09/towards-automated-dynamic-analysis-linux-based-embedded-firmware.pdf
- https://gtfobins.github.io/
- https://jfrog.com/blog/unboxing-BusyBox-14-new-vulnerabilities-uncovered-by-claroty-and-jfrog/
- https://github.com/asmitaj08/FuzzingBusyBox_LLM
- https://pages.cs.wisc.edu/~remzi/OSTEP/
- https://www.usenix.org/legacy/event/osdi02/tech/waldspurger/waldspurger.pdf
- https://github.com/rchtsang/ffxe
- https://anonymous.4open.science/r/ffxe-anon