Fuzzing delle ECU: trovare i bug in UDS, DoIP e SOME/IP

Il fuzz testing invia a un sistema dati malformati, inattesi o casuali e osserva se si verificano malfunzionamenti. Per le ECU automotive è uno dei modi più efficaci per trovare bug di memory safety e problemi di robustezza negli stack di protocollo, prima che li trovino gli attaccanti o il campo.

Perché fare fuzzing sulle ECU?

Le ECU elaborano continuamente input non attendibili: richieste diagnostiche via UDS, chiamate di servizio via SOME/IP, frame su CAN, pacchetti su Ethernet. Questi parser sono in genere scritti in C o C++, spesso riutilizzati da una generazione all’altra e raramente testati con input ostili. Una sola scrittura out-of-bounds in un handler diagnostico può portare a un denial of service o, peggio, all’esecuzione di codice su una centralina rilevante per la safety.

Che cosa sottoporre a fuzzing

Interfaccia	Bersagli tipici
UDS (ISO 14229) su CAN / DoIP	Session control, ReadDataByIdentifier, WriteDataByIdentifier, SecurityAccess, RoutineControl, servizi di trasferimento
DoIP (ISO 13400)	Vehicle identification, routing activation, framing dei messaggi diagnostici
SOME/IP e SOME/IP-SD	Service discovery, chiamate di metodo, serializzazione dei payload
CAN / CAN FD	Decodifica dei segnali, segmentazione ISO-TP, routing del gateway
Wireless (Bluetooth, Wi-Fi)	Pairing, profili, management frame su unità IVI e telematiche

Tre tipi di fuzzing

1. Fuzzing casuale (dumb): byte o frame casuali. Economico e veloce, efficace per i problemi superficiali dei parser, ma la maggior parte degli input viene scartata subito.
2. Fuzzing protocol-aware (generation-based): gli input vengono generati a partire da un modello del protocollo, ad esempio service ID UDS validi con sub-function e lunghezze mutate. Raggiunge percorsi di codice molto più profondi.
3. Fuzzing basato su database: usa i database diagnostici ODX/CDD per sapere quali DID e routine esistono, con i relativi tipi di dato e lunghezze, e muta esattamente quelli. È l’approccio più efficiente quando i database sono disponibili.

Rilevare i malfunzionamenti su hardware reale

A differenza del fuzzing software, di solito non è possibile collegare un sanitizer a una ECU. I fuzzer usano invece degli oracoli:

• Controlli di liveness: la ECU risponde ancora a un TesterPresent o a un DID noto
• Reset imprevisti: sessioni che cadono, risposte di ECU reset, DTC impostati
• Anomalie di timing: tempi di risposta molto al di fuori della baseline
• Effetti a livello di bus: messaggi ciclici mancanti da parte della ECU sotto test
• Monitoraggio di alimentazione e corrente al banco

Ogni anomalia va salvata insieme all’esatta sequenza di input, così che gli sviluppatori possano riprodurla e analizzarla.

Inserire il fuzzing nel processo di rilascio

Il vantaggio maggiore si ottiene quando il fuzzing non è un’attività una tantum, ma viene eseguito a ogni release software:

• Eseguite le campagne in CI su un banco o su un rig HIL
• Tracciate i risultati per ECU e versione software
• Collegate i risultati alla TARA e ai requisiti di cybersecurity come evidenze per la ISO/SAE 21434

È esattamente il workflow che la nostra suite di security testing AutoST automatizza, con motori di fuzzing per UDS, DoIP, SOME/IP e CAN/CAN FD. Per analisi manuali più approfondite, il nostro team offre penetration test automotive.