25 vulnerabilità in RTOS Zephyr, comprese quelle sfruttate tramite pacchetto ICMP

Ricercatori del Gruppo NCC hanno pubblicato risultati gratuiti dell'audit del progetto zeffiro, sviluppando un sistema operativo in tempo reale (RTOS), finalizzato ad equipaggiare dispositivi conformi al concetto di Internet of Things (IoT, Internet of Things). Durante l'audit è stato rivelato 25 vulnerabilità in Zephyr e 1 vulnerabilità in MCUboot. Zephyr è stato sviluppato con la partecipazione di società Intel.

In totale, sono state identificate 6 vulnerabilità nello stack di rete, 4 nel kernel, 2 nella shell dei comandi, 5 nei gestori delle chiamate di sistema, 5 nel sottosistema USB e 3 nel meccanismo di aggiornamento del firmware. Due problemi sono considerati critici, due sono elevati, 9 sono moderati, 9 sono bassi e 4 sono da considerare. Problemi critici riguardano lo stack IPv4 e il parser MQTT, quelli pericolosi riguardano la memoria di massa USB e i driver USB DFU. Al momento della divulgazione delle informazioni, erano state preparate correzioni solo per le 15 vulnerabilità più pericolose; i problemi che portano alla negazione del servizio o associati a difetti nei meccanismi aggiuntivi di protezione del kernel non sono stati risolti.

Nello stack IPv4 della piattaforma è stata identificata una vulnerabilità sfruttabile da remoto che porta al danneggiamento della memoria durante l'elaborazione di pacchetti ICMP modificati in un certo modo. Un altro problema serio è stato riscontrato nel parser del protocollo MQTT, causato dalla mancanza di un corretto controllo della lunghezza del campo di intestazione e può portare all'esecuzione di codice in modalità remota. Problemi di negazione del servizio meno gravi si riscontrano nello stack IPv6 e nell'implementazione del protocollo CoAP.

Altri problemi possono essere sfruttati localmente per causare un rifiuto di servizio o eseguire codice a livello di kernel. La maggior parte di queste vulnerabilità sono legate alla mancanza di controlli adeguati degli argomenti delle chiamate di sistema e possono portare alla scrittura e alla lettura di aree arbitrarie della memoria del kernel. I problemi si estendono anche allo stesso codice di elaborazione delle chiamate di sistema: chiamare un numero di chiamata di sistema negativo provoca un overflow di numeri interi. Il kernel ha inoltre identificato problemi nell'implementazione della protezione ASLR (address space randomization) e nel meccanismo per impostare i canary mark sullo stack, rendendo questi meccanismi inefficaci.

Molti problemi riguardano lo stack USB e i singoli driver. Ad esempio, problemi nell'archiviazione di massa USB possono causare un buffer overflow ed eseguire codice a livello di kernel quando il dispositivo è collegato a un host USB controllato dall'aggressore. Una vulnerabilità in USB DFU, un driver per il caricamento di un nuovo firmware tramite USB, consente di caricare un'immagine firmware modificata nella Flash interna del microcontrollore senza utilizzare la crittografia e bypassando la modalità di avvio sicuro con verifica dei componenti utilizzando una firma digitale. Inoltre, è stato studiato il codice del bootloader aperto MCUboot, in cui è stata rilevata una vulnerabilità benigna,
che può portare a un overflow del buffer quando si utilizza il protocollo SMP (Simple Management Protocol) sull'UART.

Ricordiamo che in Zephyr è previsto un solo spazio di indirizzi virtuali condiviso globale (SASOS, Single Address Space Operating System) per tutti i processi. Il codice specifico dell'applicazione è combinato con un kernel specifico dell'applicazione per formare un eseguibile monolitico che può essere caricato ed eseguito su hardware specifico. Tutte le risorse di sistema vengono determinate in fase di compilazione, riducendo le dimensioni del codice e aumentando le prestazioni. L'immagine del sistema può includere solo le funzionalità del kernel necessarie per eseguire l'applicazione.

È interessante notare che tra i principali vantaggi di Zephyr menzionato sviluppo pensando alla sicurezza. Approvatoche tutte le fasi di sviluppo siano sottoposte a fasi obbligatorie di conferma della sicurezza del codice: test fuzzing, analisi statica, test di penetrazione, revisione del codice, analisi dell'implementazione delle backdoor e modellazione delle minacce.

Fonte: opennet.ru

Aggiungi un commento