Les filtres de sécurité compliquent l’enquête d’un chercheur sur un possible bug du noyau Linux
Le chercheur en sécurité Daniel Fox Franke affirme que les contrôles de sécurité automatisés d’un service d’IA fermé l’ont empêché à plusieurs reprises d’utiliser le système pour enquêter sur des plan...
Le chercheur en sécurité Daniel Fox Franke affirme que les contrôles de sécurité automatisés d’un service d’IA fermé l’ont empêché à plusieurs reprises d’utiliser le système pour enquêter sur des plantages impliquant l’utilitaire open source ripgrep. Il s’est finalement tourné vers des modèles à poids ouverts pour poursuivre son analyse.
Franke a déclaré à The Register que ce travail avait commencé après plusieurs plantages de ripgrep au cours d’une longue session Codex. Il a demandé à un agent d’examiner le problème, notamment la manière dont ripgrep et la bibliothèque C musl géraient l’allocation mémoire. Le classificateur de cybersécurité d’OpenAI a signalé plusieurs des requêtes qui ont suivi, en particulier celles portant sur la reproduction du plantage et l’analyse du tas.
Selon Franke, il a restreint la tâche et demandé explicitement au système de se concentrer sur l’analyse du code source plutôt que sur la reproduction du plantage ou l’examen des fichiers core. Le classificateur a néanmoins continué à bloquer les réponses. Franke a déclaré que le modèle GPT-5.6 Sol sous-jacent semblait disposé à l’aider, mais que le système de filtrage distinct interrompait l’échange.
Il a également indiqué ne pas avoir essayé les modèles d’Anthropic, car il s’attendait à ce que leurs restrictions soient plus sévères. Les messages d’erreur d’OpenAI le renvoyaient vers ses programmes Trusted Access destinés aux chercheurs en sécurité, mais il n’a pas entrepris la procédure de vérification. Il a décrit le processus comme fastidieux et déclaré que les modèles ouverts restaient une solution viable.
Les modèles ouverts ont fourni différents niveaux d’assistance
Franke a utilisé Kimi K3 de Moonshot AI et GLM-5.2 de Z.ai au cours de son enquête. Il attribue à K3 l’identification d’éléments suggérant que le problème pourrait impliquer le noyau Linux, tout en jugeant peu fiables certains de ses raisonnements ultérieurs et sujets à des conclusions non étayées. GLM-5.2 a ensuite examiné ce travail et contribué à constituer ce que Franke considère comme un dossier technique plus solide.
Le chercheur a souligné que l’enquête n’était pas terminée. Il pense que les plantages sont causés par un défaut du noyau et a identifié un possible bug du noyau, mais n’a pas établi que le défaut suspecté était responsable des défaillances de ripgrep. Il a indiqué qu’il n’existait actuellement aucun correctif et que le problème ne semblait pas exploitable.
Cet épisode met en évidence une tension persistante dans les outils de sécurité fondés sur l’IA : les garde-fous destinés à limiter l’aide apportée aux attaquants peuvent également entraver le débogage légitime et la recherche de vulnérabilités. Franke estime que des outils inaccessibles ou peu coopératifs risquent de pousser les chercheurs vers des systèmes à poids ouverts, dont le comportement peut être inspecté et ajusté plus directement.
