Depende del proveedor y puede depender de la inferencia. Es por eso que usamos escáneres de vulnerabilidad, y por qué los escáneres de vulnerabilidad se equivocan al asumir la culpa ante una evidencia poco clara.
Vendor
Al menos un proveedor, Red Hat, mantiene una base de datos de mapeo de vulnerabilidad a CVE , donde se enumeran todos CVEs que se aplican al software en su distribución. Las páginas de detalles analizarán cuál es el estado de su software con respecto a esa vulnerabilidad:
- No es vulnerable en la configuración distribuida por RedHat (consulte CVE-2015-0202 )
- Abordado por la errata de seguridad de Red Hat (RHSA) (consulte CVE-2015-0192 )
- No se considera lo suficientemente importante como para que Red Hat lo aplique (consulte CVE-2014-2532 para RHEL 5)
Entonces, si estás usando Red Hat, estás bien. Toma los CVE que te preocupan y puedes consultarlos y ver lo que han hecho. Sin embargo, la mayoría de los vendedores no están organizados. (Consulte también Ciclo de vida de una vulnerabilidad de seguridad ) .
Algunos proveedores también tienen el hábito de liberar ciertas correcciones para pagar a los clientes de soporte solo, a veces incluso solo bajo solicitud específica. Te puedes imaginar cómo eso complica esta investigación.
Inferencia
Debido a que MITRE intenta realizar un seguimiento de los anuncios de proveedores relacionados con las CVE, puede ser posible determinar qué problemas ha abordado un proveedor mirando las referencias de "Fuente externa" dentro de un CVE. Por ejemplo, al leer los detalles de CVE-2015-0202 , Se puede ver que OpenSuSE y Mandriva tienen enlaces. El enlace de OpenSuSE describe su versión de actualización parcheada (y el enlace de Mandriva está roto). Red Hat no está enlazado aquí; como vimos anteriormente, no son vulnerables, por lo que la ausencia de esta lista no es prueba de vulnerabilidad.
MITRE también mantiene Clave de referencia / mapas CVE . Por ejemplo, el Map for Source MS , proporciona un mapa muy ordenado y organizado de CVE a los parches de Microsoft. Pero, como con todo lo demás,
Tenga en cuenta que la lista de referencias puede no estar completa.
Escáneres de vulnerabilidad
Confiar en las personas para mantener las bases de datos actualizadas y publicadas es, por así decirlo, falible. Es por eso que utilizamos escáneres de vulnerabilidad para verificar. Los escáneres de vulnerabilidad son también falibles: más específicamente, las pruebas que se eliminan de información limitada (como los anuncios de la versión de la pancarta de servicio) a menudo fallarán. Digamos que OpenSSH-2.3.4 es vulnerable a CVE-2002-1234, que está parcheado en OpenSSH-3.4.5. Red Hat puede tomar el parche de seguridad específico para esa vulnerabilidad y realizar una copia de seguridad, creando OpenSSH-2.3.4p2, que aún se anunciará como OpenSSH-2.3.4 en el banner de servicio. Dado que el escáner está desactivando la versión y no está ejecutando el error para probar que está allí, considerará que el sistema es vulnerable.
Cuando el escáner haga eso, debemos investigar el problema con todos los elementos encontrados arriba y probar que no es realmente vulnerable.
Summary
Por razones obvias, los proveedores no proporcionan una lista ordenada de cosas que eligieron no parchear. Honestamente, si a ellos les importara lo suficiente como para rastrearlo, probablemente también les importaría lo suficiente como para solucionar los problemas. Pero, por sí misma, todo lo que haría una lista de ese tipo es hacer que se vean mal, así que no hay mucha motivación para hacerlo.
Podemos conformarnos con lo que brindan, y podemos inferir cosas cuando investigamos y no podemos encontrar pruebas de la disponibilidad de parches. Estas no son soluciones exactas. Dicho esto, recuerdo la vida antes de que empezara la base de datos CVE, y estamos mucho mejor de lo que solíamos ser.