eBPF est une force pour la défense, mais c'est aussi du code qui s'exécute dans le noyau : à ce titre, il constitue une surface d'attaque qu'il faut connaître pour la réduire. Cette page adopte le point de vue du défenseur : pourquoi charger un programme eBPF est un privilège sensible, quelles parties du sous-système un attaquant peut viser, et ce que cela implique concrètement. Aucun mode opératoire offensif ici, seulement de quoi comprendre le risque et le maîtriser. Public : administrateur ou ingénieur sécurité. Pour les contre-mesures pas à pas, voir durcir eBPF.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Comprendre pourquoi eBPF est à la fois un outil de défense et une surface d'attaque
- Identifier les trois zones de risque du sous-système
- Situer les failles historiques du vérificateur
- Évaluer ce qu'un attaquant déjà privilégié peut faire avec eBPF
- Relier ce constat aux mesures de durcissement
Pourquoi eBPF est une surface d'attaque
Section intitulée « Pourquoi eBPF est une surface d'attaque »Le paradoxe est réel : la même technologie qui permet de détecter les intrusions (voir Tetragon, Falco) donne, entre de mauvaises mains, un moyen d'observer et manipuler le système au plus bas niveau. Un programme eBPF s'exécute dans le noyau, voit passer les données avant qu'elles ne soient chiffrées ou après qu'elles ont été déchiffrées, et peut, selon son type, influencer le comportement du système.
La surface d'attaque d'eBPF se décompose en trois zones distinctes, qu'il faut traiter séparément.
Zone 1 : le chargement par un utilisateur non privilégié
Section intitulée « Zone 1 : le chargement par un utilisateur non privilégié »Historiquement, un utilisateur sans privilège pouvait charger certains programmes eBPF. C'est la zone la plus dangereuse, car elle transforme n'importe quel compte local en point de départ potentiel : il suffit d'une faille dans le noyau exploitable depuis un programme eBPF pour passer d'un simple utilisateur à root.
C'est pourquoi les distributions récentes désactivent l'eBPF non privilégié par défaut (le sysctl kernel.unprivileged_bpf_disabled, détaillé dans durcir eBPF). Fermer cette porte annule à elle seule toute une classe d'exploits publics, qui ne fonctionnaient que depuis un appelant non privilégié.
Zone 2 : le vérificateur lui-même
Section intitulée « Zone 2 : le vérificateur lui-même »Le vérificateur est le gardien qui garantit qu'un programme est sûr. Mais c'est du code, complexe, et le code a des bugs. Un défaut dans le vérificateur peut lui faire accepter un programme qui, en réalité, viole ses propres règles, par exemple en accédant à une mémoire hors limites.
Ce n'est pas théorique. CVE-2021-3490 (CVSS 7.8, HIGH) en est l'exemple type : un défaut dans le suivi des bornes 32 bits des opérations logiques (ET, OU, OU exclusif) laissait passer des lectures et écritures hors limites dans le noyau, ouvrant la voie à l'exécution de code arbitraire. La faille était dans le mécanisme censé tout empêcher.
Zone 3 : l'abus par un attaquant déjà privilégié
Section intitulée « Zone 3 : l'abus par un attaquant déjà privilégié »La troisième zone concerne un attaquant qui a déjà obtenu les privilèges nécessaires (par une autre faille, un identifiant volé, un conteneur trop permissif). eBPF devient alors un outil pour s'installer discrètement : observer le trafic, capturer des identifiants en clair au moment où une application les manipule, ou se dissimuler. C'est le domaine des rootkits eBPF, traité en détail dans rootkits eBPF.
Le point clé pour le défenseur : à ce stade, eBPF n'est pas le vecteur d'entrée, c'est un moyen de persistance et de furtivité. La défense se joue donc aussi en aval : surveiller les programmes eBPF chargés, car un programme inattendu peut trahir une compromission déjà en cours.
Ce que voit le défenseur
Section intitulée « Ce que voit le défenseur »La bonne nouvelle, c'est qu'eBPF est observable. Tout programme chargé est visible avec bpftool, quel que soit l'outil qui l'a posé. Sur une machine saine au repos, la liste est courte et explicable :
sudo bpftool prog show | grep -E '^[0-9]+:' | awk '{print $2}' | sort | uniq -c | sort -rn 6 cgroup_skb 6 cgroup_device 1 tracingCes entrées viennent de systemd (filtrage réseau et périphériques des services). Tout ce qui s'écarte de cette référence connue mérite une enquête. Un programme kprobe ou tracing que vous n'avez pas déployé est un signal fort. La visibilité est votre meilleur atout : un attaquant peut charger un programme, il ne peut pas facilement le rendre invisible à un défenseur qui sait où regarder.
Réduire la surface
Section intitulée « Réduire la surface »Face à ces trois zones, la démarche est cohérente et tient en quelques principes, développés dans le guide de durcissement.
- Fermer la zone 1 : garder l'eBPF non privilégié désactivé.
- Réduire la zone 2 : maintenir le noyau à jour, la seule parade aux failles du vérificateur.
- Surveiller la zone 3 : auditer régulièrement les programmes chargés, appliquer le moindre privilège (
CAP_BPFplutôt queroot).
Ces mesures ne brident pas les usages légitimes d'eBPF : un outil d'observabilité ou de sécurité déployé par vos soins tourne parfaitement dans ce cadre. Elles ferment seulement les portes qu'un attaquant chercherait à emprunter.
À retenir
Section intitulée « À retenir »- eBPF est à double tranchant : outil de défense, mais aussi surface d'attaque car il exécute du code dans le noyau.
- Zone 1, le chargement non privilégié : la plus dangereuse, désactivée par défaut sur les distributions récentes.
- Zone 2, le vérificateur : c'est du code, il a eu des failles (ex. CVE-2021-3490, CVSS 7.8) ; la parade est le noyau à jour.
- Zone 3, l'abus par un attaquant privilégié : eBPF sert alors de persistance et de furtivité, pas de vecteur d'entrée.
- eBPF reste observable :
bpftoolmontre tout programme chargé ; l'inexpliqué est suspect. - Réduire la surface ne bride pas les usages légitimes : c'est du moindre privilège appliqué au sous-système.