Discussion :

[Jade Emy]

Grave faille RCE non authentifiée (CVSS 9.9) dans les systèmes GNU/Linux en attente de divulgation complète, la vulnérabilité permet l'exécution de code à distance non authentifiée (RCE).

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 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 : Annonce de Simone Margaritelli

Et vous ?

Pensez-vous que cette découverte est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

Les développeurs Linux corrigent les failles de sécurité plus rapidement qu'Apple, Google ou même Microsoft, selon un rapport du Google Project Zero

Un bogue vieux de 12 ans dans polkit permet d'obtenir des privilèges « root » sur les principales distributions GNU/Linux, Ubuntu et Red Hat ont déjà publié des correctifs

Durant la dernière décennie, Windows 10 a eu moins de vulnérabilités que Linux, macOS X et Android, selon une étude

[nl.smart]

Hi,

Thanks for the info, we hope soon a patch.

[SQLpro]

Tiens c'est amusant...
"
la divulgation complète de la faille aura lieu en octobre 2024
"
Dans le libre on n'est pas obligé de publier la faille dès que l'on en a connaissance alors que les éditeurs (oracle, MS...) ont cette obligation ?

A +

[chrtophe]

la divulgation complète de la faille aura lieu en octobre 2024
"
Dans le libre on n'est pas obligé de publier la faille dès que l'on en a connaissance alors que les éditeurs (oracle, MS...) ont cette obligation ?

La divulgation "grand-public" est planifiée en octobre pour laisser le temps de la corriger justement. Le principe est aussi appliqué aux produits commerciaux.

Il ne faut pas confondre le processus d'attribution d'une CVE avec une obligation de divulgation au sens légal.

Pour une entreprise, les obligations légales leurs sont opposable, selon des lois et juridictions différentes selon les pays.

Pour l'Europe, voici ce que j'ai pu trouver :

Le CRA prévoit des sanctions financières substantielles pour les opérateurs économiques qui ne respectent pas les exigences réglementaires, soulignant la gravité des enjeux en matière de cybersécurité. En effet, le texte prévoit une amende administrative pouvant aller jusqu’à 15 millions d’euros ou, si l’auteur de l’infraction est une entreprise, jusqu’à 2,5 % de son chiffre d’affaires annuel mondial total réalisé au cours de l’exercice précédent, le montant le plus élevé étant retenu.

Les contributeurs opensource ne sont pas des opérateurs économiques. Par contre, je pense que des produits commerciaux utilisant de l'opensource sont concernés par la sanction.

Mais quid pour une entité commerciale proposant un produit opensource ?

CRA=Cyber Resiliance Act

[NaoyNC]

La divulgation pratiquement complète a eu lieu à cause d'un leak du CERT VINCE sur le blog de @evilsocket, le chercheur, et l'exploit est dispo dans l'issue GitHub de cups-browsed. Y a plus qu'à attendre le correctif rapidement mais perso, je conseille de désactiver cups-browsed en attendant.

[floyer]

C’est assez fou de lire un article insinuant une CVE critique de Linux… alors qu’elle porte plutôt sur un service (Cups) certes fourni par les différentes distributions, mais pas installé sur les serveurs Web par exemple. Je peux maintenant dormir tranquille. Ceci-dit, l’article source était peu précis aussi. Merci NoayNC pour la précision.