FatFs : 7 failles touchent des millions d’appareils embarqués

Sept vulnérabilités ont été rendues publiques dans FatFs, une bibliothèque de système de fichiers très répandue dans l’embarqué pour la gestion de volumes FAT et exFAT. Le sujet mérite une attention particulière côté sécurité applicative, firmware et IoT : FatFs est souvent intégrée directement dans des firmwares, des SDK constructeurs, des cartes de développement, des équipements industriels, des périphériques USB, des objets connectés et des produits grand public, parfois sans visibilité claire dans l’inventaire logiciel. Selon les informations relayées par The Hacker News à partir de travaux de recherche publiés par les découvreurs et des éléments fournis par l’éditeur du composant, l’exploitation passe par des systèmes de fichiers malformés, notamment via des supports amovibles ou des images de disque construites pour déclencher des erreurs de parsing.

Le risque ne se limite pas à un simple plantage. Les effets documentés incluent des corruptions mémoire, des dénis de service et, selon le contexte d’intégration, une possibilité de prise de contrôle plus large si la corruption est exploitable. Dans un environnement embarqué, ce type de faille est particulièrement sensible : une bibliothèque compacte, jugée « bas niveau » et souvent considérée comme stable, peut se retrouver présente dans des millions d’appareils sans mécanisme de mise à jour robuste. L’angle supply chain est donc central. Une dépendance minuscule, embarquée depuis des années dans un BSP, un SDK ou un firmware de référence, peut rester invisible dans les SBOM, non suivie dans les processus de veille, et difficile à corriger une fois les produits déployés chez les clients.

Au moment de la rédaction, les références précises de chaque CVE, les scores CVSS détaillés et le découpage exact par version ne sont pas tous repris de manière exhaustive dans la source secondaire fournie. Par prudence, il faut donc s’en tenir à ce qui est confirmé : sept failles ont été divulguées dans FatFs, elles concernent le traitement de systèmes de fichiers FAT/exFAT malformés, et une version corrigée a été publiée par l’éditeur du composant. La source originale à privilégier pour l’évaluation et la remédiation reste l’advisory officiel du projet FatFs et, selon les cas, les bulletins des fournisseurs de SDK, RTOS, cartes ou équipements qui l’intègrent.

Point opérationnel : si votre produit monte, parcourt, indexe ou analyse des médias FAT ou exFAT provenant d’un utilisateur, d’un partenaire, d’un atelier de maintenance ou d’un équipement tiers, il faut considérer l’exposition comme réelle jusqu’à vérification de la version embarquée de FatFs et de l’application effective du correctif publié par l’éditeur.

Versions affectées

La difficulté principale, sur ce dossier, est la visibilité. FatFs est rarement consommée comme un paquet système classique ; elle est plus souvent copiée sous forme de sources dans un dépôt firmware, intégrée dans un SDK constructeur ou packagée dans un middleware. Cela complique l’identification des versions vulnérables à grande échelle, notamment dans des chaînes industrielles où plusieurs générations de produits réutilisent un même socle logiciel.

D’après les éléments rendus publics dans la source relayée, les vulnérabilités touchent des versions de FatFs antérieures à la version corrigée publiée par l’éditeur. En l’absence, dans la source secondaire fournie, d’une matrice de versions exhaustive et vérifiable ligne par ligne, il ne faut pas extrapoler des numéros de version précis. La bonne pratique consiste à :

• identifier la copie exacte de FatFs embarquée dans le produit, souvent via les fichiers ff.c, ff.h, ffconf.h et éventuellement diskio.c ;
• relever la bannière de version, les commentaires d’en-tête ou l’historique de patch interne ;
• comparer cette version à la version corrigée indiquée dans l’advisory officiel du projet ;
• vérifier si votre fournisseur de SDK ou votre constructeur a publié un backport plutôt qu’une montée de version complète.

Ce qu’il faut inventorier concrètement

• firmwares d’objets connectés utilisant une carte SD, microSD, une clé USB ou un stockage amovible ;
• équipements industriels et automates lisant des supports de maintenance ou d’export ;
• imprimantes, caméras, enregistreurs, terminaux de paiement, appareils médicaux et passerelles réseau avec import/export local ;
• cartes de développement et produits basés sur des piles logicielles de fabricants de microcontrôleurs ;
• bootloaders, modules de mise à jour hors ligne, modes recovery et outils de diagnostic qui montent des volumes FAT ;
• applications desktop ou mobiles de support qui manipulent des images de firmware ou des médias destinés à l’appareil.

Pourquoi la version réelle est souvent difficile à retrouver

Dans l’embarqué, il est fréquent que la bibliothèque ait été importée il y a plusieurs années puis modifiée localement. Le nom du composant reste FatFs, mais le code peut contenir des adaptations spécifiques au matériel, au RTOS ou à la couche diskio. Un inventaire basé uniquement sur les noms de répertoires ou sur une SBOM incomplète peut donc manquer la dépendance. C’est précisément ce qui rend ce type de faille dangereux à l’échelle supply chain : la présence de la bibliothèque est banale, sa traçabilité ne l’est pas.

Pour les organisations ayant un parc hétérogène, la première étape n’est pas le patch, mais la cartographie :

• recherche de chaînes FatFs, ChaN, ff.c, ff.h dans les dépôts ;
• analyse de firmwares binaires à la recherche de signatures textuelles ;
• interrogation des fournisseurs pour obtenir la nomenclature logicielle ;
• corrélation avec les produits qui acceptent des médias amovibles ou des images de disque externes.

Vecteur d’attaque

Le vecteur d’attaque décrit est lié au parsing de structures FAT ou exFAT malformées. Concrètement, un attaquant prépare un support de stockage, une image disque ou un contenu se présentant comme un volume valide, mais contenant des métadonnées incohérentes, des valeurs hors plage, des tailles inattendues, des entrées de répertoire construites pour perturber la logique du parseur, ou d’autres anomalies destinées à déclencher un comportement mémoire non sûr dans la bibliothèque.

Dans un système classique, on pense immédiatement à une clé USB piégée. Dans l’embarqué, le spectre est plus large :

• carte SD insérée dans un appareil photo, une dashcam, un enregistreur ou un automate ;
• clé USB utilisée pour une mise à jour locale, un export de logs ou une importation de configuration ;
• image de disque montée depuis un canal réseau puis traitée comme un support local ;
• support de maintenance manipulé par un technicien ;
• média préparé en amont dans une chaîne logistique ou un atelier.

Chaîne d’exploitation typique

Le scénario le plus plausible est le suivant :

• l’attaquant prépare un volume FAT ou exFAT malformé ;
• ce volume est présenté à l’appareil, physiquement ou via un mécanisme logiciel ;
• le firmware appelle des fonctions de montage, de parcours ou de lecture de répertoire ;
• la bibliothèque traite des champs invalides et entre dans un état non prévu ;
• le résultat est un crash, un blocage, une corruption mémoire ou, selon l’environnement, une primitive exploitable plus loin.

Le point important pour les équipes produit est que l’attaque peut être déclenchée très tôt dans le cycle de traitement, parfois au simple montage automatique du média, sans qu’un fichier spécifique ait besoin d’être ouvert par l’utilisateur. Si le firmware scanne automatiquement le contenu pour afficher une liste de fichiers, vérifier la présence d’un paquet de mise à jour, indexer des photos, lire une configuration ou générer une miniature, la surface d’attaque est déjà exposée.

Pourquoi l’impact varie fortement selon l’intégration

FatFs n’est pas un produit autonome ; c’est une brique logicielle intégrée dans un contexte matériel et logiciel donné. La gravité réelle dépend donc de plusieurs facteurs :

• architecture mémoire du microcontrôleur ou du processeur ;
• présence ou non de protections mémoire ;
• compilateur, options d’optimisation et protections activées ;
• privilèges du code qui manipule le système de fichiers ;
• enchaînement avec d’autres composants vulnérables ;
• comportement applicatif après détection d’une erreur.

Sur un appareil simple, l’effet observable sera souvent un redémarrage, un gel ou une impossibilité de lire le média. Sur un produit plus complexe, notamment si le code vulnérable est exécuté dans un contexte privilégié et que la corruption mémoire est contrôlable, le scénario peut devenir plus sérieux. C’est pour cette raison que les publications mentionnent non seulement le déni de service et la corruption mémoire, mais aussi une exécution de code potentielle selon le contexte.

Exemple de logique exposée côté firmware

Le code suivant illustre un schéma fréquent : montage automatique d’un volume puis parcours des fichiers au branchement d’un support. Il ne s’agit pas d’un code d’exploitation, mais d’un exemple d’intégration qui montre où se situe la surface d’attaque.

Dans ce type de logique, tout se joue avant même qu’un fichier métier soit consommé. Si les structures du volume ou du répertoire sont malformées, le parseur peut être atteint lors de f_mount, f_opendir ou f_readdir. C’est pourquoi une validation applicative tardive, par exemple sur le nom ou le contenu du fichier, ne suffit pas à neutraliser le risque.

Scénarios d’attaque concrets

• Atelier de maintenance : un support amovible utilisé pour charger une configuration ou récupérer des journaux provoque le redémarrage en boucle d’un équipement industriel.
• Chaîne logistique : un média préparé en amont est inséré dans une flotte d’appareils avant expédition, propageant un comportement défaillant à grande échelle.
• Environnement hostile : un attaquant ayant un accès physique bref à un terminal ou à une passerelle y insère un support piégé pour provoquer une indisponibilité.
• Canal indirect : une image disque reçue via le réseau est analysée localement par un composant utilisant FatFs, sans qu’aucune clé USB ne soit impliquée.

Pour les RSSI, le risque principal n’est pas seulement l’exploitation ciblée, mais aussi l’effet de masse : une bibliothèque omniprésente, un vecteur simple, et une remédiation lente sur des appareils connectés de manière intermittente ou sans mécanisme OTA fiable.

Impact

Les impacts publiquement mentionnés couvrent trois catégories : corruption mémoire, déni de service et exécution de code potentielle. En pratique, cela signifie :

• corruption mémoire : écriture ou lecture hors limites, état interne incohérent, structures corrompues ;
• déni de service : crash du processus, blocage du firmware, watchdog, redémarrages répétés, support inutilisable ;
• prise de contrôle potentielle : si la corruption est exploitable dans un contexte favorable, l’attaquant peut gagner une capacité d’exécution arbitraire ou de détournement du flux.

Dans l’embarqué, un déni de service n’est pas anodin. Un appareil qui redémarre en boucle, qui ne traite plus son média de mise à jour, ou qui se fige sur insertion d’un support peut devenir impossible à maintenir sur le terrain. Pour certains équipements, cela suffit à interrompre un service, dégrader une chaîne de production ou empêcher une collecte de données.

Autre point souvent sous-estimé : même si l’exploitation jusqu’à l’exécution de code n’est pas démontrée sur votre modèle précis, une corruption mémoire dans un composant de parsing reste un signal de qualité logicielle faible sur une surface exposée à des entrées non fiables. Elle doit être traitée comme un indicateur de risque élevé, surtout lorsqu’elle se situe dans un code exécuté avec des privilèges importants.

Comment patcher

Il n’existe généralement pas de commande universelle de type apt upgrade ou dnf update pour FatFs, car la bibliothèque est intégrée dans les sources des firmwares plutôt que distribuée comme paquet système standard. La remédiation consiste donc à mettre à jour le composant vers la version corrigée publiée par l’éditeur, puis à reconstruire et redéployer le firmware ou le logiciel concerné.

La source officielle à suivre est l’advisory du projet FatFs ainsi que, le cas échéant, les bulletins des fournisseurs qui redistribuent le composant dans leurs SDK ou BSP. Si vous dépendez d’un constructeur de cartes, d’un RTOS ou d’un framework embarqué, commencez par vérifier si un correctif packagé est déjà disponible de leur côté.

Étapes de remédiation recommandées

• identifier toutes les copies de FatFs dans vos dépôts et branches de maintenance ;
• récupérer la version corrigée publiée par l’éditeur ou le backport officiel de votre fournisseur ;
• mettre à jour les fichiers sources concernés, notamment ff.c, ff.h et la configuration associée ;
• recompiler l’ensemble des firmwares et outils qui embarquent la bibliothèque ;
• tester avec des médias valides et invalides avant déploiement ;
• publier une mise à jour OTA ou un firmware de maintenance ;
• documenter la version corrigée dans la SBOM et dans la base de connaissances sécurité.

Exemple de mise à jour dans un dépôt firmware

Le détail exact dépend de votre intégration, mais le processus ressemble souvent à ceci :

Dans un environnement avec sous-modules ou dépendances tierces importées automatiquement, la commande exacte variera. L’important est d’éviter deux pièges classiques :

• mettre à jour une seule branche alors qu’une autre ligne produit continue d’embarquer la version vulnérable ;
• corriger le dépôt principal sans corriger les outils annexes, bootloaders ou utilitaires de maintenance qui utilisent eux aussi FatFs.

Cas des distributions Linux embarquées

Si votre produit n’intègre pas directement FatFs mais s’appuie sur un paquet fourni par une distribution embarquée, il faut suivre le mécanisme de mise à jour du fournisseur. Dans ce cas, les commandes pourront être de type :

ou :

Mais ces commandes ne sont pertinentes que si le composant vulnérable est effectivement distribué sous forme de paquet par l’OS de l’équipement. Pour la majorité des usages évoqués ici, FatFs est compilée dans le firmware, et la correction passe par une reconstruction logicielle complète.

Validation après correctif

Une fois la mise à jour appliquée, il faut vérifier plus que la simple réussite de compilation :

• montage de volumes FAT et exFAT légitimes ;
• régression sur les cas limites de noms de fichiers, tailles et arborescences ;
• comportement sur médias corrompus ou incomplets ;
• stabilité en boucle d’insertion/retrait ;
• journalisation correcte des erreurs sans blocage.

Si vous exploitez des flottes chez des hébergeurs ou intégrateurs français, par exemple dans des environnements connectés via OVH ou Scaleway pour la supervision et la distribution OTA, la coordination entre mise à jour du firmware, publication des artefacts, supervision et gestion des retours terrain doit être préparée en amont. Pour des infrastructures mutualisées ou des plateformes de support opérées chez un prestataire comme o2switch, la partie critique ne sera pas l’hébergement lui-même mais la chaîne de diffusion des images et des outils de maintenance liés aux équipements.

Mitigation

Quand le patch n’est pas immédiatement déployable, il faut réduire l’exposition. Sur des produits embarqués en production, la fenêtre de remédiation peut être longue : validation réglementaire, processus industriel, dépendance à un fournisseur, absence de canal OTA, ou contraintes de disponibilité. Dans ce contexte, plusieurs mesures de mitigation sont utiles, sans remplacer le correctif.

Réduire la surface d’attaque

• désactiver temporairement la lecture automatique de médias externes si le produit le permet ;
• restreindre les fonctions d’import/export locales aux seuls cas indispensables ;
• désactiver le montage automatique au branchement ;
• réserver les opérations sur support amovible à un mode maintenance contrôlé ;
• interdire l’usage de médias non approuvés dans les procédures terrain.

Valider strictement les entrées avant traitement

La validation applicative ne corrige pas la faille dans le parseur, mais elle peut réduire certains scénarios. Par exemple :

• n’accepter que des supports initialisés par vos outils internes ;
• refuser les images de disque provenant de canaux non authentifiés ;
• vérifier signatures, manifestes ou métadonnées avant d’aller plus loin dans le traitement métier ;
• imposer une procédure de reformatage contrôlé des médias avant usage.

Il faut toutefois garder en tête que si le simple montage suffit à atteindre la bibliothèque, la validation doit être placée avant toute opération utilisant FatFs, ce qui n’est pas toujours possible selon l’architecture.

Durcir l’intégration

• isoler autant que possible le traitement des médias dans un composant séparé ;
• appliquer des garde-fous de temps et de ressources pour éviter les blocages prolongés ;
• surveiller les redémarrages watchdog après insertion d’un support ;
• journaliser précisément les erreurs de montage, d’ouverture et de lecture.

Dans les conceptions futures, il est pertinent de traiter les parseurs de formats et de systèmes de fichiers comme des composants exposés à des entrées hostiles, au même titre qu’un parseur d’image, d’archive ou de protocole réseau.

Détection

La détection de cette famille de vulnérabilités est délicate, car l’attaque peut se manifester par un comportement peu spécifique : crash, gel, redémarrage, code de retour d’erreur, corruption d’état. Il faut donc combiner détection statique, télémétrie d’exécution et procédures de triage.

Indicateurs de compromission ou d’exposition

Il n’existe pas, à ce stade des informations publiques reprises ici, d’IoC universels du type hachages, domaines ou signatures réseau. En revanche, plusieurs indicateurs techniques peuvent aider à repérer une tentative d’exploitation ou un appareil exposé :

• présence de FatFs dans le firmware ou le SDK ;
• fonctionnalités de montage de médias FAT ou exFAT accessibles à l’utilisateur ou au support ;
• redémarrages répétés après insertion d’un support ;
• erreurs inhabituelles autour de f_mount, f_opendir, f_readdir, f_open ;
• watchdog déclenché lors d’une opération de lecture de média ;
• support amovible provoquant un comportement anormal sur plusieurs appareils identiques.

Exemples de journaux utiles

Ces événements ne prouvent pas une exploitation, mais ils justifient une analyse si le déclencheur est corrélé à un média particulier ou à une opération répétable. Dans une flotte, une hausse subite des redémarrages ou des échecs de lecture après usage de supports externes est un signal faible à prendre au sérieux.

Détection statique dans les dépôts

Ces commandes permettent d’identifier rapidement les projets à auditer. Elles doivent être complétées par une revue des binaires, des sous-modules et des composants fournis par des tiers.

Approche CERT et gestion de crise

Pour les organisations françaises disposant d’un dispositif de réponse à incident, la remontée au CERT interne ou au prestataire de réponse est utile si des comportements anormaux sont observés en production. Si des impacts significatifs touchent des systèmes sensibles, la consultation des publications du CERT-FR et des autorités sectorielles peut aider à cadrer la gestion, même lorsqu’il s’agit d’une bibliothèque embarquée et non d’un service exposé sur Internet.

Perspective écosystème et risque supply chain

Ce dossier illustre un problème récurrent de l’écosystème IoT et embarqué : des composants modestes, éprouvés, omniprésents, mais peu visibles dans la gouvernance sécurité. FatFs n’est ni un framework massif ni un service réseau, pourtant son empreinte est très large. Quand une faille y est découverte, les difficultés ne sont pas tant techniques que structurelles :

• inventaire incomplet des dépendances ;
• absence de SBOM exploitable ;
• copies de code intégrées manuellement ;
• forks internes non documentés ;
• produits en fin de vie encore déployés ;
• processus de mise à jour terrain coûteux ou inexistants.

Le risque supply chain est donc silencieux. Une petite bibliothèque, intégrée à l’origine pour des raisons de simplicité et de performance, devient un point de faiblesse transversal. La leçon dépasse le cas FatFs : les composants de parsing de formats binaires, systèmes de fichiers, archives, images ou protocoles industriels doivent être suivis comme des dépendances critiques, même s’ils ne sont pas exposés directement sur le réseau.

Pour les équipes sécurité produit, cela implique plusieurs chantiers structurants :

• générer des SBOM réellement utiles pour les firmwares ;
• maintenir une traçabilité des composants importés en source ;
• lier veille sécurité, nomenclature logicielle et parc produit ;
• prévoir des campagnes de tests de robustesse sur les parseurs ;
• définir une politique de support et de patch pour les appareils déployés longtemps.

Sur le plan technique, ce type de vulnérabilité rappelle aussi l’intérêt des approches de test orientées formats : fuzzing, jeux de médias malformés, campagnes de robustesse sur cartes SD et images de disque, et instrumentation des plantages. Même lorsque le code est petit et réputé mature, les entrées binaires complexes restent une source classique de défauts mémoire.

Références et source originale

La publication de référence à consulter est l’advisory officiel du projet FatFs ainsi que les informations techniques publiées par les chercheurs à l’origine de la divulgation. La source secondaire ayant servi de point de départ éditorial est l’article de The Hacker News intitulé Unpatched Flaws Disclosed in Filesystem Bundled Into Millions of Embedded Devices. Pour la remédiation, il faut toutefois s’appuyer en priorité sur la source originale de l’éditeur du composant et sur les bulletins des fournisseurs qui l’embarquent.

En l’absence, dans la source fournie ici, d’une liste vérifiable de tous les identifiants CVE et de leurs scores CVSS, il est préférable de ne pas en publier de manière spéculative. Les équipes doivent récupérer ces références directement depuis l’advisory officiel afin d’alimenter correctement leur suivi de vulnérabilités, leur scoring interne et leur priorisation de patch.

Le point pratique à retenir est simple : toute organisation qui conçoit, maintient ou exploite des appareils manipulant des volumes FAT ou exFAT doit vérifier immédiatement la présence de FatFs, identifier la version embarquée, appliquer la version corrigée publiée par l’éditeur et renforcer les contrôles autour des supports amovibles. Pour aller plus loin sur l’hygiène de développement, l’inventaire des dépendances et le durcissement des chaînes de mise à jour, les ressources de la catégorie /categorie/pratiques apportent un complément utile et directement exploitable.