Fuzzing d’ECU : trouver des bugs dans UDS, DoIP et SOME/IP

Le fuzzing envoie à un système des données malformées, inattendues ou aléatoires et observe les défaillances. Pour les calculateurs automobiles (ECU), c’est l’un des moyens les plus efficaces de trouver des bugs de sécurité mémoire et des problèmes de robustesse dans les piles protocolaires, avant que des attaquants ou le terrain ne les trouvent.

Pourquoi fuzzer les ECU ?

Les ECU analysent en permanence des entrées non fiables : requêtes de diagnostic en UDS, appels de service en SOME/IP, trames sur le CAN, paquets sur Ethernet. Ces parseurs sont généralement écrits en C ou en C++, souvent réutilisés d’une génération à l’autre et rarement testés avec des entrées hostiles. Une seule écriture hors limites dans un gestionnaire de diagnostic peut conduire à un déni de service ou, pire, à une exécution de code sur un calculateur lié à la sûreté.

Que fuzzer ?

Interface	Cibles typiques
UDS (ISO 14229) sur CAN / DoIP	Contrôle de session, ReadDataByIdentifier, WriteDataByIdentifier, SecurityAccess, RoutineControl, services de transfert
DoIP (ISO 13400)	Identification du véhicule, activation du routage, encapsulation des messages de diagnostic
SOME/IP et SOME/IP-SD	Découverte de services, appels de méthodes, sérialisation des charges utiles
CAN / CAN FD	Décodage des signaux, segmentation ISO-TP, routage par la passerelle
Sans fil (Bluetooth, Wi-Fi)	Appairage, profils, trames de gestion sur les unités IVI et télématiques

Trois variantes de fuzzing

1. Fuzzing aléatoire (« dumb ») : octets ou trames aléatoires. Peu coûteux et rapide, efficace pour trouver les problèmes de parseur en surface, mais la plupart des entrées sont rejetées très tôt.
2. Fuzzing orienté protocole (par génération) : les entrées sont générées à partir d’un modèle du protocole, par exemple des identifiants de service UDS valides avec des sous-fonctions et des longueurs mutées. Il atteint des chemins de code bien plus profonds.
3. Fuzzing piloté par base de données : il s’appuie sur les bases de diagnostic ODX/CDD pour savoir quels DID et quelles routines existent, avec leurs types de données et leurs longueurs, puis mute exactement ceux-là. C’est l’approche la plus efficace lorsque ces bases sont disponibles.

Détecter les défaillances sur du matériel réel

Contrairement au fuzzing logiciel, on ne peut généralement pas attacher un sanitizer à un ECU. Les fuzzers utilisent donc des oracles :

• Contrôles de vivacité : l’ECU répond toujours à un TesterPresent ou à un DID connu
• Resets inattendus : pertes de session, réponses de reset de l’ECU, DTC enregistrés
• Anomalies de timing : temps de réponse très éloignés de la référence
• Effets au niveau du bus : messages cycliques manquants de la part de l’ECU testé
• Surveillance de l’alimentation et du courant sur le banc

Chaque anomalie doit être enregistrée avec la séquence d’entrées exacte, afin que les développeurs puissent la reproduire et la qualifier.

Intégrer le fuzzing au processus de release

Le bénéfice est maximal lorsque le fuzzing n’est pas une activité ponctuelle, mais qu’il s’exécute à chaque release logicielle :

• Lancez les campagnes sur un banc ou un banc HIL dans la CI
• Suivez les résultats par ECU et par version logicielle
• Reliez les résultats à la TARA et aux exigences de cybersécurité pour constituer les preuves ISO/SAE 21434

C’est exactement le workflow qu’automatise notre suite de tests de sécurité AutoST, avec des moteurs de fuzzing pour UDS, DoIP, SOME/IP et CAN/CAN FD. Pour une analyse manuelle plus poussée, notre équipe propose des tests d’intrusion automobiles.