Son útiles, simplemente no son útiles para crear exploits. Tampoco son útiles para determinar qué tan defectuoso es un software ... El número de CVE no tiene una fuerte correlación con la calidad del código.

Para lo que son útiles, es determinar, como administrador, si las versiones de un paquete de software dado que está utilizando han sido parcheadas para vulnerabilidades conocidas específicas, y el impacto potencial de las explotaciones que Se han descubierto. De esta manera, pueden incorporarse directamente a un proceso de administración de vulnerabilidades como una de las muchas herramientas que puede utilizar para garantizar que su organización administre adecuadamente el riesgo de seguridad del software.

El principal caso de uso de CVE es tener identificadores únicos para vulnerabilidades de software. Es no es una buena herramienta para medir la seguridad general de un producto y no lo ayudará con el análisis en profundidad de un error.

Debería pensar en CVE como un diccionario en lugar de una base de datos que asigna nombres estándar a vulnerabilidades para que pueda referirse a ellas sin ambigüedades en diferentes sistemas. No cometa el error de suponer que una entrada CVE le brinda una explicación completa de una vulnerabilidad o una estimación precisa del impacto.

La página About CVE deja bastante claro que la atención se centra en la estandarización :

  

CVE es:

     

• Un nombre para una vulnerabilidad o exposición
  
• Una descripción estandarizada para cada vulnerabilidad o exposición
  
• Un diccionario en lugar de una base de datos
  
• Cómo las bases de datos y herramientas dispares pueden "hablar" el mismo idioma
  
• El camino hacia la interoperabilidad y una mejor cobertura de seguridad
  
• Una base para la evaluación entre herramientas y bases de datos
  

[...]

Por lo tanto, no se pretende que CVE sea una base de datos completa de todas las vulnerabilidades conocidas en ningún producto, ya que las entradas no están verificadas por un tercero ni están necesariamente completadas. Es principalmente útil como una descripción general y para tener un identificador único que puede utilizar para solucionar el error en un parche o un informe.

Las CVE son útiles de varias maneras.

Primero, y quizás lo más importante, proporcionan un término común para una vulnerabilidad en particular. Esto hace que sea fácil asegurarse de que cuando alguien dice "viste esa vulnerabilidad de Android", estás hablando de la vulnerabilidad de Android misma . También simplifica enormemente la búsqueda de más información sobre el problema.

En segundo lugar, cuando hace clic en página del NIST sobre la vulnerabilidad , tiene información de CVSS que, si está familiarizado con la lectura de la notación, hace que sea fácil obtener una descripción general rápida de lo importante que es para que parches la vulnerabilidad en su entorno.

Como ya se dijo, son útiles ... solo depende de lo que quieras hacer. Si está realizando una auditoría de seguridad, que es como abordaré mi respuesta, es importante tener un punto de partida. Ejecutar algo como Nessus o OpenVAS le dirá que un CVE particular se correlaciona con un host. A partir de ahí, deberás investigar si hay algún exploit disponible para el uso de algo como exploit-db.com . Los exploits no siempre se enumeran con el CVE, por lo que se necesita diligencia debida.

Para mí, las CVE se parecen un poco a los términos del diccionario. Está pensado para poder comunicar fácilmente qué es algo a través de una enumeración común.

Puede leer más acerca de por qué están escritas de esa manera en enlace

Un buen CVE es este relacionado con OpenSSL: enlace

La descripción es breve, pero la página enlaza con referencias relevantes que se amplían en el CVE.

En el CVE que está utilizando como ejemplo, hay un enlace al boletín de seguridad de Android que contiene más información y enfoque de seguridad (aunque no menciona mucho). Si había una vulnerabilidad disponible, es probable que no esté compartida.

Las CVE son útiles para todos los actores de la cadena de software (desarrolladores, administradores de sistemas, clientes ...) para decidir si deben o no actuar en el software existente. La prueba de conceptos se redacta deliberadamente porque, como voy a mostrar, lleva mucho tiempo parchear las instalaciones reales .

En un mundo teórico, los parches se implementan inmediatamente en todos los dispositivos. Esto garantiza que todos los dispositivos estén parcheados y protegidos. Esto es imposible.

Elige Android ...

• T0: una vulnerabilidad en el kernel de Linux, que afecta al kernel de Android, se encuentra parcheada
• T1: Google parchea AOSP y lanza el parche
• T2: los fabricantes de dispositivos móviles (por ejemplo, LG, Motorola, Samsung) reciben el parche y lo aplican a su compilación personalizada
• T3: el parche se entrega a los consumidores mediante OTA
• T4: una empresa con miles de dispositivos empresariales Android del mismo fabricante implementa la actualización en los dispositivos de trabajo

Elige Apache ...

Esto es similar a un caso que me sucedió durante mi trabajo

• T0: se encuentra una vulnerabilidad en Apache y está parcheada, se lanza Apache
• T1: una gran empresa que usa Apache para muchas aplicaciones instaladas internamente en una variedad de servidores programa la actualización
• T2 a T100: todas las instancias de Apache se actualizan en los sistemas corporativos, con la participación de proveedores y gerentes para cumplir y programar un plan de prueba

En resumen

Los CVE son útiles para determinar "qué tan antiguo" y "qué tan arriesgado" es un software. Al examinar la gravedad y los componentes afectados, el personal de TI puede decidir si, por ejemplo, no actualizar por ahora, actualizar de inmediato, aplicar medidas de seguridad temporales adicionales (por ejemplo, firewall, proxy).

En el mundo corporativo hay una lentitud intrínseca en la actualización de software. Veo bancos que ejecutan Java < = 1.5 (de nuevo, no más tarde de 1.5 ) porque las versiones posteriores no han sido certificadas y Java 1.7 ya está al final de su vida útil. Sabemos que las empresas todavía ejecutan XP porque no saben si toda su base de software existente se ejecuta en Windows 7, ni siquiera se atreven a probar 10.

Un CVE grave, según mi experiencia, puede ser la razón para priorizar una actualización de software en un escenario corporativo estructurado.