Un débat (assez récurrent) agite en ce moment le monde de la sécurité informatique à propos de deux choses, les CVE et les CVSS. Commençons par expliquer. Un CVE (« Common Vulnerabilities and Exposures ») est juste un identificateur (par exemple, CVE-2022-4269 désigne une faille de sécurité du noyau Linux permettant à un utilisateur de planter le système). Ce sont juste des identificateurs. Ils permettent de référencer une faille de manière non ambigue et facilitent donc la communication. (« As-tu bien patché les noyaux contre CVE-2022-4269 ? ») Mais il est important de noter qu'ils ne constituent pas une évaluation de la faille ou de son importance. (CVE-2022-4269, par exemple, nécessite une configuration particulière, ne se déclenche pas toute seule et est donc assez peu grave.) Mieux, et c'est un des éléments du débat, on peut créer un CVE même pour une bogue qui n'est pas une faille de sécurité. « Avoir un CVE » n'a donc pas de valeur en soi, c'est juste déclaratif.
On notera qu'il n'existe pas de base unique d'information sur les CVE, il existe de nombreux sites, pas forcément à jour, ne donnant pas forcément beaucoup de détails.
CVSS (Common Vulnerability Scoring System) vise au contraire à fournir une évaluation de la faille. On voit tout de suite qu'on rentre dans un domaine bien plus délicat, où une certaine subjectivité est inévitable.
Le débat est ancien sur ces deux mécanismes, que beaucoup d'experts en sécurité jugent peu efficaces pour leur travail. Certains souhaiteraient par exemple qu'une vraie évaluation soit faite avant d'allouer un CVE (c'est certainement irréaliste, vu le travail que cela représenterait, d'autant plus qu'il faudrait des compétences couvrant tous les aspects de l'informatique). D'autres réclament que seul le fournisseur d'un logiciel puisse fournir une évaluation (comme le CVSS). On voit bien quelle seraient les conséquences, puisque beaucoup de fournisseurs nieraient le problème de sécurité, ou le relativiseraient (cela concerne surtout le logiciel privateur, mais le logiciel libre n'est pas à l'abri de ce risque). À l'inverse, les gens de la sécurité peuvent être tentés de gonfler la gravité d'une faille, qui justifie leur travail (pensez au battage médiatique de vulnérabilités présentées comme « on va tous mourir » et qui ont finalement fait pschiiit).
Le débat a par exemple été relancé par Daniel Stenberg (l'auteur de curl) qui a fulminé contre la « faille »
CVE-2020-19909 alors que cette bogue (bien réelle) n'a aucune conséquence en terme de sécurité. (Déjà discuté sur LinuxFr, hélas avec une traduction de l'anglais faite par une IA ivre.)
Mais je suis sûr que tout·tes les lecteurices de LinuxFr ont un avis sur comment faire mieux :-)
# La valeur qu'on leur donne :)
Posté par Julien.D . Évalué à 7.
Ah cette éternelle question.
L'un des premiers problèmes, c'est comme le suggère NVD c'est la première communication de la CVE avec la note associée. Est-ce que la politique d'attribuer une note plus élevée faute d'informations au risque de faire paniquer les utilisateurs est la bonne ? Je dirais que oui, mais en lui ajoutant également une note sur la certitude de celle-ci, le temps que des analyses plus approfondies soient faites.
Cela permettrait de distinguer une CVE assurément critique d'une autre potentielle.
Les CVE à 9.8 qui n'en sont pas finalement pas font toujours l'effet d'un enfant qui criait au loup :)
Autre point qu'un score CVE ne remonte pas, c'est le scope d'exploitation de celui-ci, en prenant comme exemple curl, est-ce qu'il s'agit d'un problème exploitable du côté ligne de commande, ou en remote, et sur quel protocole ?
Est-ce que cette CVE peut amener à un leak d'information ou "juste" un DOS ? En fonction de la réponse, sa gestion par les acteurs concernés peut-être très différente.
J'ignore comment on pourrait normaliser ces aspects, mais associer une unique note à une faille de sécurité me semble très très réducteur, au point où les CVE ne sont pas utilisables sauf à y mettre une équipe dédiée en interne pour répondre à ces questions dans le contexte de l'acteur. (entreprise, collectivité, gouvernement, etc.)
J'ai déjà eu affaire à des outils d'analyse d'artefact qui remontent des centaines de CVE sur des projets interne, mais impossible de vraiment savoir à quel point elles sont vraiment critiques, ou même exploitables (une faille sur une fonctionnalité non utilisée par exemple)
Au final, malgré l'importance de la sécurité informatique aujourd'hui, je trouve que la communication et la gestion autour des failles de sécurité n'est pas au niveau des enjeux, ou du moins reste un luxe accessible uniquement aux acteurs ayant un gros budget à y consacrer.
Et je vous parle même pas de la polique des artefacts suite à la découverte d'une CVE, on garde les artefacts vulnérables combien de temps ? et les équipes responsables font comment ? Ils mettent à jour vers la dernière version ? Et si elle n'est pas supportée par l'environnement ? On coupe l'application ? On fait des dérogations ?
Bref, c'est à se demander pourquoi aujourd'hui les développeurs mettent encore des bugs dans leurs programmes …
[^] # Re: La valeur qu'on leur donne :)
Posté par fcartegnie . Évalué à 8. Dernière modification le 11 septembre 2023 à 07:03.
C'est bien plus embêtant qu'un simple "cri au loup". Les conséquences derrière peuvent être sévères, dûes au "même sérieux" dans l'intégration de ces CVE bancales par les entreprises de sécurité.
https://media.ccc.de/v/36c3-10525-lightning_talks_day_3#t=1705
TLDW, à VideoLAN, on a dû refaire une release juste pour débloquer les installateurs sur les desktops avec antivirus, suite à une CVE invalide.
# Moi je suis d'accord...
Posté par Dring . Évalué à 10.
…avec tout le monde.
Autrement dit, oui les plaintes sont totalement légitimes. Et c'est vrai que contacter l'éditeur avant de fournir une évaluation de risque, c'est bien.
En même temps, certains éditeurs ne voudraient évidemment pas jouer le jeu et en profiteraient pour sous-estimer les gravités.
C'est vrai que les personnes qui publient les CVE ne comprennent pas grand chose au code et aux vulnérabilités.
En même temps, j'imagine pas une équipe faite de super cerveaux capables de comprendre tous les langages du monde et de se plonger dans le code de n'importe quel projet opensource en quelques heurees.
C'est vrai que créer un vent de panique et le risque de décisions irrationnelles voire plus dangereuses que la vulnérabilité elle-même, c'est mal, c'est con.
En même temps, si on doit mettre en place un process à 15 étages avant de publier une CVE, avec des validations des uns et des autres et l'obtention d'un consensus, les CVEs seront publiées 2 ans après leur découverte.
Bref, ici on est dans la recherche d'un équilibre subtil, qu'on ne trouvera pas, et qui ne pourra jamais satisfaire tout le monde à la fois. La frustration fait donc partie des effets collatéraux inévitables.
[^] # Re: Moi je suis d'accord...
Posté par Colin Pitrat (site web personnel) . Évalué à 3.
Exactement, il n'y aura pas de solution parfaite mais ce qu existe est pas mal et quelques abus ou erreurs ne veulent pas dire que tout est à jeter!
# évaluation de la gravité
Posté par Krunch (site web personnel) . Évalué à 3. Dernière modification le 06 septembre 2023 à 16:43.
Je pense que les métriques telles que CVSS peuvent rapidement dépendre de comment le logiciel est utilisé. Ça n'est pas forcément quelque chose sur lequel le fournisseur a beaucoup de visibilité. Pour CVSSv2 il s'agit notamment des métriques qui mesurent l'impact environnemental (non, l'autre). Pour CVSSv3 c'est le vecteur modifié. CVSSv4 semble renforcer ces concepts : https://www.first.org/cvss/v4-0/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Positif et negatif
Posté par pasBill pasGates . Évalué à 7.
Le problème avec ces systèmes est qu'il faut trouver quelque chose qui est compréhensible et utilisable par l'administrateur moyen sans connaissances sécurité.
Faire une analyse de menaces particulière n'est pas dans leur cordes souvent, résultat il faut leur donner une approximation et c'est ce que CVSS est pour moi.
CVE c'est un peu la même chose, un identifiant standardisé histoire que les gens puissent communiquer et se comprendre.
Ce ne sont pas des systèmes parfait loin de là, mais la question est : est-ce qu'il y a mieux, et là je n'ai encore rien vu.
[^] # Re: Positif et negatif
Posté par fearan . Évalué à 4.
Non. S'il n'a aucune connaissance en sécurité il applique tous les patchs de sécurités épicétout. S'il n'a pas le temps de se former un minimum sur la sécu alors qu'il est admin, faut pas demander plus.
Pour le reste, on pourrait avoir un système de tag, genre élévation de privilège, contournement des environnement restreints (docker, VMs, …), DOS, corruption de données, ralentissement, exploitable a distance, utilisation uniquement sur configuration spécifique…
ainsi l'admin système qui connait ce qu'il exploite peut regarder si il est impacté ou pas.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Positif et negatif
Posté par pasBill pasGates . Évalué à 3.
C'est une belle théorie…le problème est qu'en pratique le monde ne marche pas comme ça.
Mais tout cela existe déjà et CVSS va même plus loin que cela.
[^] # Re: Positif et negatif
Posté par fearan . Évalué à 4.
Si l'admin ne s'y connait pas en sécurité et veux pas installer tous les patchs je vois pas trop ce qu'on peut faire de plus.
Justement, en ajoutant une part de subjectivité cela l'expose aux critiques de dev expliquant que oui y'a une faille, mais elle ne peut se produire que dans des conditions très spécifiques qui ne sont en pratique jamais réunies.
Et comme y'a débat, ça brouille le message. A vouloir trop bien faire…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Positif et negatif
Posté par pasBill pasGates . Évalué à 4. Dernière modification le 10 septembre 2023 à 02:09.
L'admin veut le moins de changements possible, probablement ne connais pas grand chose à la sécurité mais veut aussi garder ses systèmes protégés.
Résultat lui donner un minimum d'infos (ex: cette vuln est exploitable sans authentification et par le réseau) lui dit ce qui est absolument urgent et ce qui ne l'est pas.
Aller plus loin dans les détails aiderait certains c'est sur mais beaucoup ne comprendraient pas.
Bref, CVSS a son utilité
[^] # Re: Positif et negatif
Posté par orfenor . Évalué à 3.
De toute façon s'il veut plus de détail il chercher le papier sur la CVE.
[^] # Re: Positif et negatif
Posté par octane . Évalué à 2. Dernière modification le 08 septembre 2023 à 09:27.
en fait les raisons pour patcher alors c'est quoi?
Si tu ne fais pas d'évol fonctionnelle, tu peux rester sans toucher à rien. Donc les seules raisons de patch, c'est soit une évolution (du produit, ou d'une brique), soit une vuln.
Après, j'ai croisé des boites qui patchent pas. C'était un choix (idiot, mais bon).
https://www.first.org/cvss/calculator/3.0
L'utilisation sur configuration spécifique, je vois pas. Après, je suis avocat du diable, je sais pas comment tu peux mettre ça dans un cvss. Pour connaître la config spécifique, faut creuser dans l'advisory, un score ne peut pas indiquer ça.
[^] # Re: Positif et negatif
Posté par barmic 🦦 . Évalué à 3.
En fait je pense que CVSS n'est pas tant un filtre qu'une criticité : est-ce qu'il faut t'appeler un dimanche 3h du matin pour mettre à jour la dépendance dans les heures qui suivent ou est-ce que ça peut attendre lundi ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Positif et negatif
Posté par pasBill pasGates . Évalué à 2.
Exemple :
AV = Ca vient par le réseau
PR = pas d'authentification nécessaire
Etc.
te dit que c'est urgent
[^] # Re: Positif et negatif
Posté par octane . Évalué à 3.
oui mais là tu me dis ce qu'est un score CVSS (merci je connais un peu).
Par contre tu en réponds à "configuration spécifique". Genre, tu as ton routeur cisco truc, CVSS9.9. Ca te dit: ça vient du réseau pré-auth. Donc grave.
Mais la vuln elle est où? le VPN? config par défaut? le routage dynamique? l'interface d'admin? snmp. un service quelconque? Et ça, bah CVSS il y répond pas.
[^] # Re: Positif et negatif
Posté par pasBill pasGates . Évalué à 2.
Mais ce n'est aussi pas le but de CVSS… CVSS c'est pour un premier filtre de ce qui est essentiel a deployer immediatement ou pas pour l'admin moyen. C'est au vendeur dans son advisory de donner ces details pour ceux qui veulent aller plus loin.
On peut vouloir que CVSS aille plus loin oui, mais CVSS a une utilité
[^] # Re: Positif et negatif
Posté par cg . Évalué à 4.
Moi non plus. Mais parfois le distributeur publie un avis avec une analyse pour SA config distribuée, ce qui est déjà plus précis, et parfois contre-intuitif.
Par exemple Debian¹ publie les DSA et backporte les patchs, en gardant la version d'origine quand c'est possible (genre pas trop pour Firefox quoi). Ce qui fait que quand tu fais ton scan de réseau, l'outil te dit "ouah ton Apache 2.4.24 est tout pourri par la CVE-XXX et en plus y'a un autre trou dans mod_lua.". Sauf que, tu n'utilises pas mod_lua, et le 2.4.24 a été patché pour enlever le problème lié à la CVE-XXX.
¹ la mieux distro.
[^] # Re: Positif et negatif
Posté par Psychofox (Mastodon) . Évalué à 5.
J'ai l'impression que vous vous plaignez plus des problèmes de processus que du format CVE / CVSS…
Je sais que la mode ce sont les KPI et autres indicateurs et que tout entreprise qui les mets en place et/ou qui est soumis à des audits SOC2 a tendance à vouloir des tableaux de bords avec des nombres en vert, en orange et en rouge et s'attend à ce que les ingés s'attèlent à effacer les trucs en rouge avant les audits. Et que oui malheureusement les outils qui fournissent ces tableaux de bords se basent sur les CVE et la métrique CVSS pour afficher ces mignons petit tableaux.
Mais je crois que c'est pas sur les CVE et CVSS qu'il faut gueuler, mais sur SOC2 et comment et par qui les audits sont faits, ce qui fait qu'ils sont en général une vaste blague.[1]
[1] même si ça a aussi des effets bénéfiques en forçant les entreprises à améliorer leurs process et situations.
# En fait, non. Je n'ai pas d'avis sur comment faire mieux
Posté par tisaac (Mastodon) . Évalué à 10.
Ce n'est pas que je veux te contredire mais je n'ai pas d'avis sur comment faire mieux. Pour éviter que tu ne sois pas trop déçu, j'ai réfléchi à des idées pour faire autrement ou pas:
score = [log(prix) - 1 * tg(prix/Pi) + cos(Pi) exp(prix)] * [cos²(prix)+sin²(prix)-1]+110 - degré d'alcool de la dernière boisson bue par la personne qui a découvert la vulnérabilité.En espérant avoir fait avancer le Schmilblik.
Surtout, ne pas tout prendre au sérieux !
# CVE et CVSS ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Autant je comprends les défauts potentiels voire avérés des CVSS, car il y a des enjeux autour d'un seuil qualitatif et des intérêts contradictoires, autant je n'ai pas connaissance de beaucoup de soucis propres aux CVE.
Les CVE sont des identifiants, on les retrouve dans les alertes sécurité (de chaque distribution, éditeur, projet, etc.), dans le suivi de sécurité (comme https://security-tracker.debian.org/tracker/
https://launchpad.net/ubuntu-cve-tracker etc. ), dans les outils de sécurité (trivy, les dependabot/renovate, wazuh, etc.), dans les discussions autour de la sécurité (jusque dans les étiquettes sur linuxfr.org), etc. Bref c'est comme les identifiants SPDX des licences pour les inventaires logiciels (SBOM), les UUID pour identifier des volumes, etc., etc. Il y a des tas de CVE dont chacun se contrefiche (n'utilisant pas le matériel ou le logiciel ou la version concernée), s'accommode (aucun intérêt pour la sécurité, impact faible ou inexistant dans sa situation), doit faire avec (pas de solution connue/pas de correction fournie, exemple failles sur les "vieux" CPU). Potentiellement des CVE "abusives" (auquel cas il n'y aura pas vraiment de correction à prévoir).
Globalement les avantages me semblent très largement compenser le défaut de déclaration abusive (qui ferait perdre un peu de temps à certains), sauf à montrer de l'abus est massif.
Les CVSS sont censées aider à prioriser les corrections (de critique fin du monde à un gars touché au fond du Nebraska), mais au final, sauf impossibilité (blocage fonctionnel, incapacité à tester/risquer, changement de licence, etc.) j'essaie de déployer toutes les corrections disponibles (ce qui ne règle pas le cas des non disponibles). Mais c'est un point de vue d'adminsys, pas de spécialiste sécurité. Indirectement je me base sur les CVSS via les outils de sécurité que j'utilise (trivy ou les alertes sécurité reçues parleront de gravité critique/majeure/mineure en fonction du CVSS).
[^] # Re: CVE et CVSS ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3. Dernière modification le 09 septembre 2023 à 09:02.
J'avais même oublié avoir été directement concerné comme upstream sur une CVE… cf https://www.cvedetails.com/cve/CVE-2002-1805/
# Test de lecture
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à -6.
C'était certainement un test pour voir si on a lu jusqu'au bout :
"tout·tes les lecteurices"
j'ai rien contre mais c'est un peu maladroit, je préfère la forme "standardisée" homogène (sic) utilisant le point "catalan" aussi appelé le "point median" (vous savez, c'est le caractère que les gens ne trouvent pas sur le clavier français … il faut utiliser le clavier francais/catalan #astuce )
"tou·te·s les lect·eur·ice·s"
car cette forme est reconnue dans mon plugin de désinclusification
ou une forme "militante" (coucou le cefsys )
"toutes les lectrices"
ou même une forme plus "traditionnelle"
"tous les lecteurs quels que soient leurs sexes, leurs genres ou leurs humeurs du moment"
je vais me faire moinser grave mais c'est pas grave, si ça permet de parler d'autre chose que du sujet principal ..
[^] # Re: Test de lecture
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à -10. Dernière modification le 10 septembre 2023 à 13:56.
Vous pouvez arrêter de moinser, le test est concluant. Mais pourquoi avez vous moinsé ? Vous dites rien, vous êtes timides ?
# Utilisation pragmatique
Posté par Zythom . Évalué à 7. Dernière modification le 07 septembre 2023 à 11:17.
TLDR : une mesure parmi d'autres, qui alimente l'évaluation du risque
Je considère les vulnérabilités avant tout comme des bogues. Ces bogues doivent être inventoriés et je trouve pratique qu'il y ait un référentiel global qui soit un peu sorti du rang. Et en tant que RSSI, je suis effectivement particulièrement sensible aux bogues exploitables par une personne mal intentionnée (ce qui est ma définition d'une vulnérabilité, sans doute peu orthodoxe).
Le référentiel des CVE est pratique, mais c'est surtout l'évaluation du risque de la vulnérabilité qui m'intéresse. Et le CVSS m'aide à effectuer la mesure de ce risque : la vulnérabilité est-elle facile à exploiter, et quelle est son impact sur mon entreprise.
Par contre, je ne suis ni chercheur en sécurité informatique, ni même spécialiste de manière détaillée de chaque vulnérabilité. J'ai besoin de faire confiance à des spécialistes pour m'aider à évaluer la facilité d'exploitation de la vulnérabilité, et je pars du postulat que le CVSS est une mesure faite par des spécialistes.
Mais je recoupe cette mesure avec beaucoup d'autres : l'ANSSI alerte sur le niveau d'exploitation d'une vulnérabilité, les clubs de RSSI aussi, même les réseaux sociaux quand on suit les bonnes personnes. Par exemple, j'aurai beaucoup plus confiance dans l'alerte sur un bogue DNS analysé par un certain Stéphane Bortzmeyer sur Mastodon, qu'un CVSS perdu dans la masse grandissante des alertes.
Mon problème le plus important est qu'une fois que j'ai "mon" évaluation du risque du CVE, il n'est pas facile d'imposer l'urgence de la mise en place du correctif à l'équipe en charge de la production, surtout si cette mise en place entraîne un arrêt de production, voire un risque sur la production (quand bien même nous suivons les règles env dev/recette/pré-prod/prod).
Mais cela, c'est un autre problème.
[^] # Re: Utilisation pragmatique
Posté par rictus (site web personnel) . Évalué à 2.
Je pense que dans tous les cas, la contextualisation de la faille est nécessaire, notamment par rapport aux fonctionnalités utilisées ou non d'un équipement.
Je vois dans mon entreprise, on s'alarme rapidement dès qu'il y a une CVE et avec un CVSS un peu élevé qui concerne un équipement réseau. Or celui-ci a généralement beaucoup de fonctionnalités, et la CVE ne concerne qu'une seule d'entre elles qu'on sait ne pas utiliser et donc avoir désactivé. Donc pas d'urgence à patcher et c'est des fois compliquer à faire comprendre !
Bref CVE/CVSS a l'avantage d'alerter, mais je pense qu'on ne coupe pas à devoir être un peu technique et à faire une analyse d'impact (ou non impact) de la faille dans son environnement.
# Surtout ne pas réinventer la roue
Posté par Wawet76 (site web personnel) . Évalué à 10.
Mon avis est qu'il faudrait utiliser un système existant pour noter les CVE.
Prendre quelque chose que des gens intelligents ont mit du temps à spécifier, implémenter er affiner.
Un système qui a fait ses preuves.
Donc la solution évidente : Laisser les lecteurs de CVE voter, avec comme choix "Pertinent" ou "Inutile"
[^] # Re: Surtout ne pas réinventer la roue
Posté par BAud (site web personnel) . Évalué à 2.
pas besoin d'avoir fait le MIT ;-)
[^] # Re: Surtout ne pas réinventer la roue
Posté par rictus (site web personnel) . Évalué à -1.
ah ! ah !
Pas du tout d'accord : tu pars trop du postulat que tous les votants soient techniquement pertinents. Et je dirais même que les votants ayant un avis éclairé seraient même minoritaires.
La démocratie a aussi ses limites.
# Et pour la faille webP ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 4.
Un autre exemple récent du b…l dans les CVE (pas les CVSS, j'ai bien dit les CVE) est celui de la faille webP, qui a eu plusieurs CVE, parfois attribués à tort à un logiciel (alors que la faille était dans une bibliothèque) : https://marc.info/?l=oss-security&m=169532950413908&w=2
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.