Quoi de neuf dans CVSS 4.0 ?
8 novembre 2023
0 minutes de lectureDans cet article, nous présentons le point de vue de Snyk sur le nouveau système de notation des vulnérabilités CVSS 4.0, publié le 1er novembre 2023.
Pourquoi était-ce nécessaire ?
Cette version révisée s’inscrit dans l’évolution naturelle du paysage des vulnérabilités en cybersécurité et vise à remédier aux lacunes de la méthodologie précédente. Depuis sa publication en 2016, CVSS 3 s’est révélé un outil d’évaluation fiable, utilisé par les professionnels pour déterminer l’impact potentiel et le niveau de risque de diverses vulnérabilités, aidant ainsi les organisations et les particuliers à mieux se protéger contre les cybermenaces.
Sept ans plus tard, CVSS 4.0 constitue la nouvelle version du référentiel. Elle vise à offrir une granularité accrue et à affiner davantage la méthode de notation afin de mieux s’adapter à l’évolution des cybermenaces et du paysage numérique.
Qu’est-ce qui va changer ?
Examinons les changements qui seront introduits en comparant les aspects techniques des référentiels 3.1 et 4.0.
Remarque : Les niveaux et plages de sévérité (Faible, Moyenne, Élevée et Critique) associés à chaque valeur qualitative de sévérité resteront identiques.
Paramètre Attack Vector
Le nouveau paramètre Attack Vector, outre quelques changements sémantiques visant à proposer une définition plus inclusive (par exemple, composant plutôt que système, ou physique plutôt que proximité), remplira la même fonction qu’auparavant.
Nous ne prévoyons donc aucun changement dans l’utilisation de ce paramètre pour évaluer les vulnérabilités avec CVSS 4.0.
Paramètre Attack Complexity
Le paramètre Attack Complexity de CVSS 3.1 sera divisé en deux paramètres, Attack Complexity et Attack Requirements, afin d’offrir une plus grande granularité.
Le nouveau paramètre Attack Complexity est destiné aux attaques hautement spécialisées qui impliquent « le contournement ou l’évasion de techniques renforçant la sécurité ».
Attack Requirements, quant à lui, couvrira les cas où la réussite de l’exploitation « dépend de la présence de conditions spécifiques de déploiement et d’exécution du système vulnérable qui rendent l’attaque possible ».
La principale différence entre Attack Complexity et Attack Requirements tient à la finalité des conditions spécifiques qui rendent l’attaque possible. Selon le document de spécification, Attack Requirements ne sera utilisé que pour décrire des scénarios NON couverts par le paramètre nouveau Attack Complexity (c’est-à-dire qu’il ne doit pas être utilisé pour les scénarios qui contournent les techniques d’atténuation des exploits).
Dans l’écosystème open source, nous prévoyons une utilisation moindre de ce paramètre, car Attack Complexity ne s’appliquera qu’aux attaques hautement spécialisées. En revanche, Attack Requirements sera probablement davantage utilisé, puisqu’il englobera les conditions qui « découlent naturellement du déploiement et de l’exécution du système vulnérable ».
Paramètre Privileges Required
Le nouveau paramètre Privileges Required ne comporte que de légères modifications, visant à clarifier et à simplifier sa formulation. Sa valeur reste également inchangée.
Nous ne prévoyons aucun changement dans l’utilisation de ce paramètre pour évaluer les vulnérabilités.
Paramètre User Interaction
Le document de spécification CVSS 4.0 apporte des changements notables au nouveau paramètre User Interaction, et plus précisément à ses valeurs. Cela permettra d’évaluer les conditions d’attaque avec davantage de précision.
User Interaction pourra prendre trois valeurs (contre deux dans CVSS 3.1).
None — La définition a été améliorée en mettant l’accent sur l’utilisateur humain. Cette valeur s’applique donc lorsque « le système vulnérable peut être exploité sans aucune interaction de la part d’un utilisateur humain, autre que l’attaquant ».
Passive — Cette valeur s’applique aux attaques qui peuvent être menées à la suite d’actions involontaires de la victime.
Active — Contrairement au cas précédent, cette valeur s’applique lorsque l’attaque nécessite que la victime « effectue des interactions spécifiques et délibérées avec le système vulnérable et la charge utile de l’attaquant ». Elle s’applique également lorsque les « interactions de la victime neutralisent activement les mécanismes de protection, permettant ainsi l’exploitation de la vulnérabilité ».
Ces ajouts permettront de mieux répartir les niveaux de sévérité des vulnérabilités en remplaçant les anciennes valeurs de User Interaction. L’utilisation de ce paramètre dans le processus d’évaluation des vulnérabilités va donc changer.
Triade CIA
La triade CIA ne fait l’objet d’aucune modification notable, hormis quelques reformulations visant à assurer la cohérence des définitions dans l’ensemble du document de spécification.
L’utilisation de ces paramètres devrait rester inchangée.
Paramètre Scope
Le paramètre Scope sera remplacé par Subsequent System Impact Metrics, qui permettra de mieux répartir les niveaux de sévérité et d’évaluer plus précisément l’impact d’une vulnérabilité.
Ce changement permettra non seulement de formaliser la modification de portée, mais aussi de préciser ses conséquences sur le système affecté en aval.
Cette nouvelle approche modifiera le processus d’évaluation des vulnérabilités tout en permettant d’en mesurer l’impact avec plus de précision.
Métriques de menace
Les Threat Metrics (anciennement Temporal Score) font également l’objet de changements notables, mais nous nous concentrerons sur Exploit Code Maturity. Ce paramètre sera renommé Exploit Maturity et pourra prendre quatre valeurs (contre cinq auparavant, la valeur Functional étant supprimée). Les nouvelles définitions des valeurs Exploit Maturity ont été améliorées et précisent désormais les critères à remplir pour justifier leur utilisation.
Not Defined — Cette valeur doit être utilisée lorsque « les informations fiables sur les menaces ne sont pas disponibles pour déterminer les caractéristiques de maturité de l’exploit ».
Attacked (anciennement High) — Cette valeur s’applique lorsque 1) des attaques ont été signalées ou que 2) l’exploit a atteint un degré de maturité permettant son intégration à diverses solutions, telles que des kits d’exploitation, qui visent à simplifier et à automatiser l’exploitation.
PoC — Cette valeur doit être utilisée lorsqu’au moins l’un des critères suivants s’applique :
« Une preuve de concept est accessible au public. »
« Aucune tentative d’exploitation de cette vulnérabilité n’a été signalée à notre connaissance. »
« À notre connaissance, aucune solution accessible au public ne permet de simplifier les tentatives d’exploitation de la vulnérabilité. »
Unreported — ni PoC ni Attacked, mais différent de Not Defined (cette valeur s’applique lorsque des informations sur les menaces sont disponibles).
Ces changements modifieront l’utilisation du paramètre Exploit Maturity.
Quel sera l’impact de ces changements pour les utilisateurs ?
En complément des points abordés dans la section précédente, nous examinerons trois exemples de vulnérabilités et tenterons de les évaluer avec CVSS 4.0, en expliquant notre démarche.
Exécution de code à distance affectant le package microsoft.chakracore, version 1.10.1
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H — 7.5 Élevée
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:L/SI:L/SA:L — 7.6 Élevée
L’attaque peut être menée via le réseau, d’où AV:N. Selon la spécification, AC:H doit être utilisé lorsqu’il faut contourner des protections telles qu’ASLR. Au vu des informations disponibles sur cette vulnérabilité, nous estimons que ce scénario s’applique. Rien n’indique qu’un niveau de privilèges faible ou élevé soit requis ; le paramètre est donc PR:N. La réussite de l’exploitation dépend de la présence d’un autre utilisateur humain. Toutefois, rien ne prouve suffisamment que celui-ci doive interagir activement avec la charge utile de l’attaquant ; le paramètre est donc UI:P. Puisqu’« un attaquant qui exploite avec succès la vulnérabilité pourrait prendre le contrôle d’un système affecté », la confidentialité et l’intégrité sont toutes deux compromises : VC:H, VI:H et VA:N,. Nous estimons que l’impact s’étendra également au système en aval, qui est ici la machine de la victime. Cet impact dépendra toutefois des autorisations dont disposera l’attaquant sur cette machine ; les valeurs sont donc SC:L, SI:L et SA:L.
Exécution de code à distance affectant le package ipython, version 8.10.0
CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:L — 4.2 Moyenne
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N — 1.0 Faible
Compte tenu de la fonction du package, l’attaque ne peut être menée que localement, d’où AV:L. La réussite de l’exploitation ne nécessite pas de contourner des mécanismes de sécurité, mais dépend du système d’exploitation et d’une configuration de déploiement spécifique (la bibliothèque `ctypes`, fournie par défaut avec les installations Python, doit être désactivée). Ce scénario correspond à AC:L et AT:P. L’attaquant doit également accéder à l’environnement local, ce qui implique PR:L. La victime doit interagir activement et délibérément avec la charge utile de l’attaquant en appelant la fonction vulnérable « sous Windows, dans un environnement Python où `ctypes` n’est pas disponible » ; le paramètre est donc UI:A. Au vu des informations disponibles sur cette vulnérabilité, nous estimons qu’elle n’aura aucun impact sur la triade CIA au sein du système vulnérable, mais uniquement sur le système en aval. En effet, les commandes s’exécutent sur le système hôte et l’installation de Python elle-même n’est pas directement affectée. Les commandes shell sont également « limitées au périmètre du processus en cours », ce qui correspond à SC:L et SI:L. Rien n’indiquant que la disponibilité du système en aval puisse être affectée, la valeur est SA:N.
Cross-site scripting affectant le package org.jenkins-ci.plugins:rundeck, version 3.6.11
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N — 5.4 Moyenne
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N — 5.1 Moyenne
L’attaque peut être menée via le réseau et ne nécessite pas de contourner des « techniques d’atténuation des exploits » ni de configuration de déploiement particulière pour réussir ; les valeurs sont donc AV:N, AC:L et AT:N. L’attaquant doit toutefois disposer d’un compte actif pour exploiter la vulnérabilité. Comme il s’agit d’une XSS stockée, la victime n’a pas besoin d’effectuer d’action spécifique avec la charge utile ; la valeur est donc UI:P. L’impact se répercutera sur le système en aval, puisque l’attaquant peut lire ou modifier des données dans le navigateur de la victime : VC:N/VI:N/VA:N/SC:L/SI:L/SA:N.
Des exemples officiels ont été publiés par first.org.
Conclusions générales
Nous pouvons constater d’emblée que CVSS 4.0 améliorera le processus d’évaluation des vulnérabilités. Les utilisateurs pourront déterminer plus précisément l’impact sur la sécurité, ce qui contribuera à mieux hiérarchiser les problèmes de sécurité. Concernant la répartition des niveaux de sévérité, on peut s’attendre à ce que CVSS 4.0 offre un équilibre plus satisfaisant grâce à sa granularité accrue. Cet équilibre évitera une concentration excessive des vulnérabilités dans une plage de sévérité donnée. Nous prévoyons également moins de vulnérabilités assorties d’un score de sévérité élevé, d’autant que CVSS 4.0 « conservera les mêmes plages de score pour chaque valeur qualitative de sévérité » que CVSS 3.1.
Quand CVSS v4.0 sera-t-il disponible ?
Depuis le 18 juin, l’équipe Snyk Security attribue la version CVSS 4.0 à toute nouvelle vulnérabilité de sécurité identifiée par Snyk Open Source. En plus de fonder la sévérité des nouveaux problèmes sur CVSS v4.0, Snyk intégrera progressivement les nouveaux attributs de vecteur aux différents workflows de ses gammes de produits et adaptera la manière dont les utilisateurs peuvent consulter directement ces nouvelles informations.
Si vous souhaitez en savoir plus sur l’utilisation du référentiel CVSS pour évaluer la gravité des vulnérabilités, consultez notre article d’introduction à l’évaluation des vulnérabilités.
Références :
CVSS 4.0 :
https://www.first.org/cvss/v4.0/examples