Alors, il y a sans doute déjà des doublons vu que justement, Red Hat et d'autres sont capable d'assigner des numéros via leur rôle de CNA.
CVE était censé préallouer des numéros pour chaque CNA afin d'éviter que le même numéro soit donné à deux vulns différentes.
Dans le cas ou doublon s'applique à la même vukn sous deux numéros, pourquoi pas, en imaginant que chercheur A remonte à redhat et chercheur B à canonical par exemple. Dans les faits, ce n'est pas très génant. Cela arrive aussi quand une vuln a deux CVE (auth bypass + code exec par exemple). Deux vulns, un produit, un seul correctif.
La question du score est aussi déjà un souci
ouais, mais là, c'est plus CVE, c'est cvss. Et ça fait partie des défauts. La manière de scorer change beaucoup. J'ai fait suffisamment de pentest pour savoir que le scoring est extrêmement souple. Le client veut tout plus bas que 7? pas de soucis. Le management râle et veut que tout soit à plus de 8? vazy mon gars.
la majeur partie des failles n'ont pas d'exploitation
pas d'exploitation ou pas de code d'exploitation public?
Ca dépend ce qu'on appelle exploitation. Une vuln qui permet de faire une SQLi sur un site web, c'est une exploit ou pas? (hint: ça peut dépendre de la base de son schéma, et des droits associés). Un heap overflow dans Chrome, c'est exploitable? Il te faudra pas mal de semaines de dev pour y répondre.
Travailler sur une vuln publiquement connue, qui a de grandes chances d'être patchée alors qu'on dev un poc d'exploit? Sérieusment? Alors oui, si la vuln est trivialement exploitable, pourquoi pas, sinon, mieux vaut chercher + pertinent. Et je parle pas des vulns inintéressantes (Dos, etc..)
[^] # Re: L'essentiel en français
Posté par octane . En réponse au lien CVE program faces swift end after DHS fails to renew contract, leaving security flaw tracking in lim. Évalué à 2.
CVE était censé préallouer des numéros pour chaque CNA afin d'éviter que le même numéro soit donné à deux vulns différentes.
Dans le cas ou doublon s'applique à la même vukn sous deux numéros, pourquoi pas, en imaginant que chercheur A remonte à redhat et chercheur B à canonical par exemple. Dans les faits, ce n'est pas très génant. Cela arrive aussi quand une vuln a deux CVE (auth bypass + code exec par exemple). Deux vulns, un produit, un seul correctif.
ouais, mais là, c'est plus CVE, c'est cvss. Et ça fait partie des défauts. La manière de scorer change beaucoup. J'ai fait suffisamment de pentest pour savoir que le scoring est extrêmement souple. Le client veut tout plus bas que 7? pas de soucis. Le management râle et veut que tout soit à plus de 8? vazy mon gars.
pas d'exploitation ou pas de code d'exploitation public?
Ca dépend ce qu'on appelle exploitation. Une vuln qui permet de faire une SQLi sur un site web, c'est une exploit ou pas? (hint: ça peut dépendre de la base de son schéma, et des droits associés). Un heap overflow dans Chrome, c'est exploitable? Il te faudra pas mal de semaines de dev pour y répondre.
Travailler sur une vuln publiquement connue, qui a de grandes chances d'être patchée alors qu'on dev un poc d'exploit? Sérieusment? Alors oui, si la vuln est trivialement exploitable, pourquoi pas, sinon, mieux vaut chercher + pertinent. Et je parle pas des vulns inintéressantes (Dos, etc..)