Un célèbre chercheur en cybersécurité a révélé une vulnérabilité RCE non authentifiée contre tous les systèmes GNU/Linux (et d’autres). Mais la vulnérabilité n’a toujours pas de CVE assigné, ni de correctif fonctionnel. Des organisations comme Canonical, RedHat et d’autres ont confirmé la sévérité de la faille, qui est de 9.9. Si les développeurs se disputent encore pour savoir si certains problèmes ont un impact sur la sécurité, la divulgation complète de la faille aura lieu en octobre 2024.
Une faille de sécurité critique affectant tous les systèmes GNU/Linux – et potentiellement d’autres – a été identifiée par le célèbre chercheur en sécurité Simone Margaritelli. La vulnérabilité, qui permet une exécution de code à distance non authentifiée (RCE), a été reconnue par des acteurs majeurs de l’industrie tels que Canonical et Red Hat, qui ont confirmé sa gravité avec un score CVSS de 9,9 sur 10.
Depuis le début du mois de septembre 2024, Simone Margaritelli a révélé l’existence d’une vulnérabilité RCE non authentifiée (CVSS 9.9) dans les systèmes GNU/Linux sans donné de détails précis afin de laisser aux développeurs le temps de résoudre le problème. Malgré cela, aucun correctif n’est actuellement disponible. Les discussions entre le chercheur et les développeurs ont permis de convenir d’un calendrier de divulgation :
- 30 septembre : divulgation initiale à la liste de diffusion sur la sécurité d’Openwall.
- 6 octobre : divulgation publique complète des détails de la vulnérabilité.
Il est intéressant de noter que l’attribution d’identifiants CVE (Common Vulnerabilities and Exposures) à ce problème a été retardée. Simone Margaritelli estime qu’au moins trois CVE devraient être attribués, voire jusqu’à six, en raison de la nature multi-dimensionnelle des vulnérabilités concernées.
Canonical et Red Hat ont non seulement confirmé la gravité de la vulnérabilité, mais travaillent également activement à l’évaluation de son impact et au développement de correctifs. Cependant, certains développeurs seraient en train de débattre de l’impact sur la sécurité de certains aspects des vulnérabilités, ce qui pourrait contribuer à retarder la publication d’un correctif.
Le manque d’informations détaillées a plongé les utilisateurs individuels et les experts en sécurité dans un état d’inquiétude accru. Sans savoir quels composants, fonctions ou versions spécifiques sont affectés, les organisations ne sont pas en mesure de prendre des mesures proactives pour protéger leurs systèmes. En outre, l’absence d’assignations CVE soulève des questions sur la coordination et la communication entre les chercheurs en sécurité, les fournisseurs et les organisations responsables de l’énumération des vulnérabilités.
Bien qu’un score CVSS de 9,9 indique une sévérité critique, il est important d’aborder la situation avec une perspective équilibrée. Toutes les vulnérabilités de gravité élevée ne sont pas facilement exploitables dans le monde réel. Par exemple :
- CVE-2024-7589 : Une vulnérabilité d’exécution de code à distance SSH initialement évaluée à 9,8 a ensuite été réévaluée à 8,1 en raison de la difficulté d’exploitation.
- CVE-2024-38063 : Une vulnérabilité d’exécution de code à distance du système Windows avec un score CVSS de 9,8 a attiré l’attention, mais a été jugée très difficile à exploiter après une analyse approfondie par des experts en sécurité.
Ces exemples soulignent l’importance d’une analyse technique détaillée pour comprendre pleinement l’impact d’une vulnérabilité.
Dans l’attente de la divulgation complète et des correctifs ultérieurs, les utilisateurs et les administrateurs devraient :
- Rester informés en suivant les mises à jour provenant de sources d’information fiables sur la sécurité et les communications officielles des fournisseurs.
- Revoir et améliorer les mesures de sécurité existantes, telles que les pare-feu et les systèmes de détection d’intrusion.
- Se préparer à un déploiement rapide des correctifs dès qu’ils seront disponibles.
Voici les déclarations de Simone Margaritelli concernant la vulnérabilité :
J'ai passé les 3 dernières semaines de mon congé sabbatique à travailler à plein temps sur cette recherche, ce rapport, cette coordination, etc. dans le seul but d'aider et je n'ai eu droit qu'à de la condescendance parce que les développeurs ne peuvent tout simplement pas accepter que leur code est merdique - divulgation responsable : c'est fini.
L'article va être amusant, pas seulement pour les détails techniques, pas seulement parce que ce RCE était là depuis plus d'une décennie, mais aussi comme un exemple de la façon dont il ne faut PAS gérer les divulgations.
J'écris des logiciels, je comprends, je comprends que quelqu'un puisse être sur la défensive à propos de ce qu'il écrit, je le comprends vraiment. Mais bon sang, si votre logiciel fonctionne sur tout depuis 20 ans, vous avez la responsabilité d'assumer et de corriger vos bugs au lieu d'utiliser votre énergie à expliquer au pauvre bâtard qui les a signalés à quel point il a tort, même s'il vous donne littéralement PoC après PoC et prouve systématiquement que vos hypothèses sur votre propre logiciel sont erronées à chaque commentaire. C'est tout simplement insensé.
Je voulais juste ajouter, par souci de clarté, que j'ai *trop de respect* pour les gens de Canonical qui ont essayé d'aider et de servir de médiateurs depuis le début, je ne sais vraiment pas comment ils font pour garder leur sang-froid comme ça.
Ceci va être la déclaration d'ouverture de l'article. C'est un commentaire réel de la conversation github. Je veux dire, ce n'est pas faux ...
"Du point de vue de la sécurité générique, un système Linux complet tel qu'il est aujourd'hui n'est qu'un fouillis sans fin et sans espoir de failles de sécurité attendant d'être exploitées."
Et il rajoute :
Et OUI : j'ADORE faire de la pub pour ce genre de choses parce qu'apparemment le sensationnalisme est le seul langage qui force ces gens à réparer.source: developpez
