Protect Your Linux Desktop From Malicious USB Devices

SYNTHÈSE STRUCTURÉE

Contexte : la menace des périphériques USB malveillants

L’intervenant rappelle que les USB malveillants (badUSB, USB killer) existent depuis les années 2010 et peuvent simuler un clavier pour injecter des commandes, ou envoyer des surtensions pour détruire un appareil. Il précise : « If you specifically target an individual machine and know exactly what they are running, all manner of exploits are possible. » La menace est réelle pour les environnements sensibles (gouvernements, entreprises, militaires), mais moins pour un usage domestique.

Le patch proposé : HID OMG detect

Un patch noyau (version 2) a été soumis pour ajouter un module de détection passive des périphériques HID malveillants. Il utilise trois critères :

Entropie du timing des frappes (keystroke timing entropy)
Latence de branchement et de frappe (plug and type latency)
Empreinte descriptive USB (USB descriptive fingerprinting)

Quand un seuil configurable est dépassé, le module émet un avertissement dans dmesg et suggère une action utilisateur (ex. via USBGuard). L’intervenant précise : « The driver does not block, delay, or modify HID input events. »

Critique de Greg Kroah-Hartman : pourquoi ne pas utiliser eBPF ?

Greg Kroah-Hartman (mainteneur noyau) a répondu : « That’s cute, but no need to get security kernel involved as this is a new feature, not a bug triage. Also, why not do this as an eBPF program instead as you have full access to the HID data stream there. » L’idée est que eBPF permet d’exécuter du code noyau sandboxé sans modifier le noyau, ce qui est plus adapté pour une fonctionnalité de détection.

Problèmes d’implémentation : faux positifs et cas particuliers

Benjamin (autre développeur) souligne plusieurs écueils :

Hypothèses erronées sur les périphériques HID : « That’s a strong assumption that actually depends on the report descriptor of the device. » Par exemple, les claviers Bluetooth ont un ID de rapport en octet 0, et les périphériques gyroscopiques envoient un flux continu d’événements qui serait considéré comme suspect.
Cas des keyloggers légitimes : un logiciel de capture de frappe pour vidéo n’est pas malveillant, contrairement à un script inconnu. La distinction est difficile à automatiser.
Périphériques non-clavier : les câbles de charge espions ou les clés de sécurité (U2F) envoient aussi des flux d’événements. « Not all devices are keyboards. »

Problème fondamental : concurrence entre pilotes HID

Le patch tente de s’attacher à tout périphérique USB, mais sans implémenter de callback de correspondance (match). Cela crée une race condition : un seul pilote HID peut être attaché à un périphérique donné. L’intervenant résume : « There can only be one HID driver attached to a specific HID device and we have multiple HID drivers in the subsystem. » Soit le pilote normal est chargé (pas de sécurité), soit le pilote de sécurité est chargé (pas de fonctionnalité normale).

Alternatives recommandées par les mainteneurs

Benjamin propose trois approches plus solides :

Fonctionnalité noyau HID : intégrer la détection directement dans le cœur HID (difficile à vendre).
Module séparé appelé par HID core : plus facile à justifier, mais encore complexe.
eBPF au niveau HID : la meilleure option, car elle permet de contrôler depuis l’espace utilisateur à la fois le programme eBPF et la partie utilisateur.

Solutions existantes : USBGuard et autres

L’intervenant mentionne USBGuard, un framework qui implémente des listes blanches/noires basées sur les attributs des périphériques. Il recommande : « The most sensible thing to do is only whitelist very specific devices. The keyboard, the mouse, probably not even thumb drives. » Pour les environnements critiques, il suggère d’utiliser un système sandboxé pour les clés USB.

Verrouillage matériel : la seule vraie solution

La conclusion est sans appel : « Software can be breached. You can work around software. » Pour des données critiques, il faut empêcher tout accès physique :

Prison laptops : ports USB internes uniquement, inaccessibles sans outillage spécialisé.
Serveurs en baie verrouillée : « Stick it in a box that you cannot get into that needs a key to access it. »
Contrôle d’accès à la salle : un boîtier verrouillé ne sert à rien si la pièce elle-même n’est pas sécurisée.

CONCEPTS CLÉS

BadUSB : périphérique USB qui se fait passer pour un clavier (ou autre) pour exécuter des commandes malveillantes.
USB killer : périphérique qui envoie des surtensions pour détruire le port USB et potentiellement la carte mère.
eBPF (extended Berkeley Packet Filter) : technologie permettant d’exécuter du code noyau sandboxé sans modifier le noyau.
Race condition : situation où le résultat d’une opération dépend de l’ordre d’exécution de plusieurs processus, pouvant mener à des comportements imprévisibles.
HID (Human Interface Device) : protocole standard pour les périphériques d’entrée (clavier, souris, manette).

CONCLUSION

Le message principal est que la détection logicielle des périphériques USB malveillants est un problème complexe, sujet à des faux positifs et à des limitations architecturales. L’approche par patch noyau direct est rejetée au profit de solutions plus flexibles comme eBPF ou USBGuard. Pour une sécurité maximale, le verrouillage matériel (ports internes, boîtiers verrouillés) reste la seule garantie fiable. L’intervenant conclut avec pragmatisme : « Don’t plug in random weird USB devices that you don’t know what they are and you’re probably going to be mostly fine. »