Fats in the open: sept vulnérabilités qui exposent les caméras, les distributeurs automatiques de billets et les drones

La société de sécurité RunZero a récemment révélé une batterie de sept vulnérabilités dans FatFs, la bibliothèque légère C qui interprète et gère les volumes FAT et exFAT sur des milliers d'appareils embarqués. Bien que le nom puisse sembler technique, la participation est directe: Cela affecte les caméras, distributeurs automatiques de billets, kiosques publics, drones, contrôleurs industriels et fourches de matériel, les appareils qui acceptent souvent les cartes SD ou les penders et lancent firmware avec peu ou pas de défenses de mémoire moderne.

Parmi les échecs en suspens figurent un débordement complet (CVE-2026-6682) qui peut produire une fausse longueur de lecture et conduire à la corruption de la mémoire et à l'exécution de code, et des erreurs dans la gestion des champs d'étiquettes et des noms longs dans exFAT qui permettent d'obtenir un point de support pour l'exploitation. RunZero qualifie les vulnérabilités entre Media et High Gravity et rappelle que beaucoup sont exploitables par un support physique malveillant ou un fichier de mise à jour manipulé. Un seul des sept est corrigé dans l'amont officiel (un bloc de problèmes qui était utilisé pour accrocher avec des tables GPT malformées), laissant la plupart des risques entre les mains des intégrateurs et des fabricants.

Le problème pratique est la gouvernance des logiciels: FatFs est essentiellement maintenu par un seul développeur et il n'y a pas de canal de communication robuste, de liste de sécurité ou de réponse consolidée lorsqu'une défaillance est détectée. Cela transforme la correction en un puzzle qui finit souvent en patchs ad hoc dans chaque SDK et produit qui incorpore la bibliothèque. Le résultat est une longue fenêtre d'exposition sur les appareils déjà déployés, comme dans les cas précédents où les entreprises et les fournisseurs ont mis des années à distribuer des corrections.

Il y a une autre lecture pertinente: les vulnérabilités ont été découvertes non seulement par l'inspection manuelle, mais aussi à l'aide d'un flux d'outils IA pour le flou qui a construit runZero. Cette approche automatisée a permis de constater des défaillances qu'une vérification précédente n'avait pas décelées. Cela montre que Les techniques de fuzzing assistées par des modèles et agents automatisés sont déjà capables de trouver des vecteurs exploitables avec peu d'effort, donc garder les vulnérabilités silencieuses ne protège plus personne.

Pour les développeurs de firmware et les gestionnaires de produits la priorité est immédiate : localiser la copie de FatFs qui est intégrée dans leur chaîne d'outils et évaluer le code qui enveloppe les appels à la bibliothèque. Il ne suffit pas de mettre à jour une unité; il est nécessaire d'examiner comment les noms de fichiers, les champs d'étiquettes et les tailles déclarées par la bibliothèque sont gérés, et d'appliquer une validation stricte des limites avant toute strcpy, memove ou lecture basée sur une taille qui vient du système de fichiers. Il est également approprié de compiler avec l'atténuation de la mémoire (par exemple protection de la batterie, ASLR / DEP si RTOS le supporte, -fstack-protector, fortify) et d'ajouter des contrôles dans le temps de fonctionnement pour détecter des lectures anormales.

Si vous gérez des appareils déjà déployés, vous devez supposer que les ports physiques et les canaux de mise à jour sont des vecteurs de risque. Limiter l'accès physique, désactiver l'automontage si possible, exiger l'authentification et la signature pour les mises à jour du firmware, et surveiller le comportement log et périphérique après les insertions médias. Dans les environnements critiques, imposer des contrôles physiques (blocage, surveillance) et des politiques opérationnelles sur qui et comment il peut relier des moyens amovibles réduit la probabilité d'exploitation.

Au niveau coordonné, l'industrie devrait exiger des pratiques exemplaires dans les bibliothèques essentielles : maintenance soutenue, listes de sécurité publique et processus d'intervention et de livraison de patchs aux projets en aval. Pendant ce temps, les intégrateurs devraient traiter les bibliothèques comme les FatFs comme des composants à haut risque et planifier des tests de sécurité continus, y compris le buzzing dirigé et l'examen des « rappeurs » que chaque produit met en œuvre autour de FatFs, parce que de nombreuses vulnérabilités proviennent du code auxiliaire, pas de la librairie en soi.

Pour plus d'informations, lisez la note runZero et la documentation originale de FatFs, et prenez comme guides de sécurité de référence pour les dispositifs IoT. Le rapport RunZero explique les techniques et fournit des preuves conceptuelles, et la page du projet FatFs fournit le contexte pour la maintenance et les versions. Le rapport de RunZero et la page des FatFs ( ChaN - FatFs) sont des points de départ utiles. Il est également recommandé d'examiner les ressources communautaires sur la sécurité de l'IdO pour orienter les mesures d'atténuation opérationnelles et de conception, comme le projet OWASP pour les appareils connectés : Projet OWASP IoT.

Bref, ces défaillances de FatFs se rappellent que la sécurité de la chaîne d'approvisionnement de logiciels embarqués est aussi faible que son maillon moins bien desservi. Si votre produit touche FAT / exFAT: identifier, vérifier, garer et atténuer; si votre organisation exploite des appareils: réduire la surface d'attaque physique et exiger des signatures et des contrôles dans les mises à jour. La fenêtre immobilière ne peut être fermée que si les fabricants, les responsables et les opérateurs agissent rapidement et de manière transparente.