Linux Security est toujours trop dépendante des agents basés sur EBPF, explique Armo.
Un fournisseur israélien a pu échapper à plusieurs outils de sécurité d’exécution de Linux en utilisant un nouveau rootkit de preuve de concept (POC) qui, selon lui, révèle les limites de nombreux produits dans cet espace.
Le travail de Cloud et Kubernetes Security Company Armo, le POC est appelé «durcissement», un mot Portmanteau qui combine l’idée d’une «guérison» avec l’interface du noyau Linux io_uring que la société a utilisée dans son POC de contournement.
En utilisant le durcissement, Armo a constaté qu’il était possible d’échapper à trois outils de sécurité Linux à des degrés divers: FALCO (créé par Sysdig mais maintenant un projet de graduation de fondation de calcul natif de Cloud), Tetragon de isovalent (maintenant partie de Cisco) et Microsoft Defender.
Falco était aveugle au durcissement, tandis que le défenseur n’a pas pu détecter le durcissement ou une gamme d’autres logiciels malveillants communs. Tetragon, en revanche, a pu détecter IO_URING, mais uniquement lorsque vous utilisez KPROBES et les crochets LSM, qui, selon Armo, ne sont pas utilisés par défaut.
Selon Armo, le problème avec les trois est une dépendance excessive sur les agents basés sur les paquets de Berkeley étendus (EBPF), qui surveillent le système comme une approche simple pour obtenir la visibilité des menaces. Malgré les avantages de cela, tout le monde dans l’industrie ne pense pas que c’est un bon design.
«Les appels système ne sont pas toujours garantis pour être invoqués; IO_URING, qui peut les contourner entièrement, est un exemple positif et excellent.
L’approche IO_URING est un angle mort EBPF Les outils n’ont pas pu détecter, a-t-il noté. « Ce mécanisme permet à une application utilisateur d’effectuer diverses actions sans utiliser d’appels système.
Longue liste de cves
L’API IO_URING est dans Linux depuis la version 5.1 en 2019, lorsqu’elle a été ajoutée pour surmonter le problème de la performance d’E / S « non bloquante » inefficace ou « non bloquante » dans la bibliothèque AIO native (Libaio) existante.
Essentiellement, les programmes peuvent soumettre plusieurs demandes d’E / S au noyau via une étape intermédiaire appelée tampon d’anneau. Cela permet à l’application de faire autre chose en attendant que l’opération d’E / S se termine.
L’inconvénient est que IO_URING peut agir comme une autoroute dans le noyau qui peut être maltraité, comme en témoigne le rootkit de durcissement d’Armo. Le danger de cela est attesté par le nombre constant de défauts de niveau CVE dans l’interface IO_URING depuis son apparence.
Armo a déclaré qu’il était motivé pour créer le Rootkit pour attirer l’attention sur deux problèmes. La première était que, bien que la technique IO_URING bien documentée pendant au moins deux ans, les vendeurs de l’espace de sécurité Linux n’avaient pas encore réagi au danger.
Le deuxième objectif était d’attirer l’attention sur des défis architecturaux plus profonds dans la conception des outils de sécurité Linux sur lesquels un grand nombre de clients comptent pour se protéger:
«Nous voulions mettre en évidence le manque d’attention approprié dans la conception de solutions de surveillance qui sont compatibles vers l’avant. Plus précisément, ces solutions devraient être compatibles avec de nouvelles fonctionnalités dans le noyau Linux et aborder de nouvelles techniques», a déclaré Schendel.
En d’autres termes, pour obtenir une meilleure sécurité Linux, les logiciels devraient anticiper de nouvelles attaques plutôt que de modifier constamment sa conception après coup.
Comment les vendeurs ont-ils répondu?
C’est peut-être le point clé d’Armo: le rythme lent du changement et a revendiqué la réponse détendue des fournisseurs de sécurité Linux à la question de la sécurité du noyau.
Lorsqu’ils sont contactés par Armo, les responsables de Falco ont reconnu le problème avec le logiciel et ont déclaré qu’ils travaillaient sur un plugin qui offrirait une meilleure visibilité.
Armo a eu moins de succès avec Microsoft. « Malheureusement », a déclaré Schendel, « Microsoft n’a pas répondu malgré plusieurs tentatives de notre part pour tendre la main et s’engager avec eux. » .
Et Isovalent, a-t-il écrit, a dit à Armo que Tetragon n’était pas vulnérable car il a fourni la «flexibilité de s’accrocher au fond n’importe où».
Isovalent a réitéré le même point dans les commentaires de cette publication, contestant l’affirmation d’Armo selon laquelle Tetragon dépendait des appels système:
« Tetragon ne s’appuie pas sur la surveillance de Syscall » comme suggéré dans le blog d’Armo « , a déclaré Liz Rice, directeur open source d’Isovalent, Liz Rice. « Tetragon offre la possibilité d’utiliser des systèmes, mais il peut utiliser EBPF pour s’accrocher à de nombreuses autres zones du noyau également, y compris l’API du module de sécurité Linux. »
« Il s’agit d’une approche beaucoup plus robuste pour détecter les événements pertinents en matière de sécurité tels que l’accès aux fichiers – y compris l’accès via IO_URING », a-t-elle déclaré, ajoutant: « L’un des avantages de Tetragon est qu’il filtre les événements, seuls les événements, seuls à la stratégie.
Rice a également publié une vidéo YouTube pour sauvegarder son point.
Notamment, les projets open source (Falco, Tetragon) ont répondu au contact d’Armo concernant son POC de durcissement, tandis que le représentant du logiciel propriétaire (Microsoft) ne l’a pas fait. Cela pourrait, bien sûr, refléter simplement la disparité de la taille des organisations impliquées.
La mise en garde évidente avec Armo est que ses affirmations sur les lacunes dans d’autres produits aident à commercialiser sa propre plate-forme de sécurité Linux Time qui, naturellement, ne souffre pas des mêmes problèmes. Cependant, cela a suggéré certaines stratégies de détection pour d’autres fournisseurs de sécurité, notamment en préconisant l’implantation de l’instrumentation de sécurité d’exécution du noyau (KRSI).
À tout le moins, a-t-il dit, le logiciel Linux devrait chercher à surveiller une utilisation inhabituelle dans l’interface IO_URING.
« Par exemple, si une application qui n’a jamais utilisé io_uring commence soudainement à la tirer parti, c’est un drapeau rouge clair », a écrit le schendel d’Armo.
