Quelle est l'utilité des entrées CVE?
La plupart des entrées CVE ne sont pas complétées par une explication complète du bogue lui-même, même une preuve de concept démontrant le bogue. Tout ce qu'ils ont, c'est une description abstraite de très haut niveau d'un effet secondaire possible, par ex. CVE-2016-8412 indique,
Une vulnérabilité d'élévation de privilèges dans la caméra Qualcomm pourrait permettre à une application malveillante locale d'exécuter du code arbitraire dans le contexte du noyau. Ce problème est considéré comme élevé car il nécessite d'abord de compromettre un processus privilégié. Produit: Android. Versions: Kernel-3.10, Kernel-3.18. Android ID: A-31225246. Références: QC-CR # 1071891.
La description est dépourvue de toute information utile, par ex. le bloc de source vulnérable (car c'est Android), une analyse pertinente, un correctif possible (facultatif), etc. Ces types de CVE sont-ils utiles du point de vue de la recherche en matière de sécurité? Servent-ils à quelque fin que ce soit, sinon à être un indice de la façon dont un logiciel est bogué?
Ils sont utiles, ils ne sont tout simplement pas utiles pour construire des exploits. Ils ne sont pas utiles non plus pour déterminer à quel point un logiciel est buggé ... Le nombre de CVE n'a pas de forte corrélation avec la qualité du code.
Ce qu'ils sont utiles, c'est de déterminer, en tant qu'administrateur, si les versions d'un progiciel donné que vous utilisez ont été corrigées pour des exploits connus spécifiques, et les impacts potentiels des exploits qui ont été découverts . De cette façon, ils peuvent alimenter directement un processus de gestion des vulnérabilités comme l'un des nombreux outils que vous pouvez utiliser pour vous assurer que votre organisation gère correctement les risques de sécurité des logiciels.
Le principal cas d'utilisation de CVE est d'avoir des identifiants uniques pour les vulnérabilités logicielles. C'est pas un bon outil pour mesurer la sécurité globale d'un produit et ne vous aidera pas dans l'analyse approfondie d'un bogue.
Vous devez considérer CVE comme un dictionnaire plutôt que comme une base de données qui attribue des noms standard aux vulnérabilités afin que vous puissiez vous y référer sans ambiguïté sur différents systèmes. Ne faites pas l'erreur de supposer qu'une entrée CVE vous donne une explication complète d'une vulnérabilité ou une estimation précise de l'impact.
La page À propos de CVE indique clairement que l'accent est mis sur la normalisation :
CVE est:
- Un nom pour une vulnérabilité ou une exposition
- Une description standardisée pour chaque vulnérabilité ou exposition
- Un dictionnaire plutôt qu'une base de données
- Comment des bases de données et des outils disparates peuvent "parler" la même langue
- Vers l'interopérabilité et une meilleure couverture de sécurité
- Une base d'évaluation parmi les outils et les bases de données
[...]
CVE n'est donc pas censé être une base de données complète de toutes les vulnérabilités connues d'un produit, car les entrées ne sont ni vérifiées par un tiers ni nécessairement complètes. Il est principalement utile comme aperçu et pour avoir un identifiant unique que vous pouvez utiliser pour corriger le bogue dans un correctif ou une écriture.
Les CVE sont utiles de plusieurs manières.
Premièrement, et peut-être le plus important, ils fournissent un terme commun pour une vulnérabilité particulière. Cela permet de garantir facilement que lorsque quelqu'un dit "avez-vous vu que Android"), vous parlez de la même Android. Il simplifie également considérablement la recherche d'informations supplémentaires sur le problème.
Deuxièmement, lorsque vous cliquez sur page du NIST sur la vulnérabilité , il contient CVSS informations qui, si vous êtes familier avec la lecture la notation, vous permet d'obtenir rapidement un aperçu de la mesure dans laquelle il est essentiel de corriger la vulnérabilité de votre environnement.
Pour moi, les CVE sont un peu comme des termes de dictionnaire. Il est censé être capable de communiquer facilement ce que quelque chose est via une énumération commune.
Vous pouvez en savoir plus sur la raison pour laquelle ils sont écrits de cette façon sur https://cve.mitre.org/about/faqs.html#b4
Un bon CVE est celui qui concerne OpenSSL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6304
La description est courte mais la page contient des liens vers des références pertinentes qui élargissent davantage la CVE.
Dans le CVE que vous utilisez comme exemple, il y a un lien vers Android bulletin de sécurité qui héberge plus d'informations et Security Focus (bien qu'il ne mentionne pas grand-chose). S'il y avait un exploit disponible alors c'est probaby non partagé.
Comme déjà dit, ils sont utiles ... cela dépend juste de ce que vous voulez faire. Si vous effectuez un audit de sécurité, c'est ainsi que j'aborderai ma réponse, il est important d'avoir un point de départ. L'exécution de quelque chose comme Nessus ou OpenVAS vous dira qu'un CVE particulier est en corrélation avec un hôte. À partir de là, vous devrez rechercher s'il existe des exploits disponibles à l'aide de quelque chose comme exploit-db.com . Les exploits ne sont pas toujours répertoriés avec le CVE, donc une diligence raisonnable est nécessaire.
Les CVE sont utiles à tous les acteurs de la chaîne logicielle (développeurs, administrateurs système, clients ...) pour décider d'agir ou non sur les logiciels existants. La preuve de concepts est délibérément expurgée car, comme je vais le montrer, il faut beaucoup de temps pour patcher les installations réelles.
Dans un monde théorique, les correctifs sont déployés immédiatement sur tous les appareils. Cela garantit que tous les appareils sont patchés et protégés. C'est impossible.
Choisissez Android ...
- T0: Une vulnérabilité dans le noyau Linux, affectant le Android, est trouvée et corrigée
- T1: Google corrige AOSP et publie le correctif
- T2: les fabricants de téléphones portables (par exemple LG, Motorola, Samsung) reçoivent le correctif et l'appliquent à leur version personnalisée
- T3: le patch est fourni par OTA aux consommateurs
- T4: une entreprise avec des milliers d'appareils Android Business du même fabricant déploie la mise à jour sur les appareils de travail
Choisissez Apache ...
Ceci est similaire à un cas qui m'est arrivé pendant mon travail
- T0: une vulnérabilité dans Apache est trouvée et corrigée, Apache est publié
- T1: une grande entreprise utilisant Apache pour un grand nombre d'applications installées en interne sur une variété de serveurs planifie la mise à niveau
- T2 à T100: toutes les instances Apache sont mises à niveau sur les systèmes de l'entreprise, impliquant les fournisseurs et les gestionnaires pour répondre et planifier un plan de test
En bref
Les CVE sont utiles pour déterminer "quel âge" et "quel est le risque" d'un logiciel. En examinant la gravité et les composants concernés, le personnel informatique peut décider, par exemple, de ne pas mettre à niveau pour l'instant, de mettre à niveau immédiatement, d'appliquer des mesures de sécurité temporaires supplémentaires (par exemple, pare-feu, proxy).
Dans le monde de l'entreprise, il y a une intrinsèque lenteur dans la mise à niveau du logiciel. Je vois des banques exécuter Java <= 1.5 (encore une fois, au plus tard 1.5) parce que les versions ultérieures n'ont pas été certifiées et Java 1.7 est déjà en fin de vie. Nous savons que les entreprises utilisent toujours XP car elles ne savent pas si toutes de leur base de logiciels existante fonctionne sur Windows 7, n'ose même pas essayer 10.
Un CVE sévère, selon mon expérience, peut être la raison de prioriser une mise à niveau logicielle dans un scénario d'entreprise structuré.