Dipende dal venditore e può fare affidamento sull'inferenza. Questo è il motivo per cui utilizziamo gli scanner di vulnerabilità e perché gli scanner di vulnerabilità sbagliano dal presupposto che la colpevolezza abbia fornito prove poco chiare.
Venditore
Almeno un fornitore, Red Hat, mantiene un database di mappatura della vulnerabilità-a-CVE , dove elencano tutti CVE che si applicano al software nella loro distribuzione. Le pagine di dettaglio descrivono quale sia lo stato del loro software rispetto a tale vulnerabilità:
- Non vulnerabile nella configurazione distribuita da RedHat (vedi CVE-2015-0202 )
- Indirizzato da Errata di Red Hat Security (RHSA) (vedi CVE-2015-0192 )
- Non considerato sufficientemente significativo da applicare patch a Red Hat (vedere CVE-2014-2532 per RHEL 5)
Quindi, se stai eseguendo Red Hat, sei bravo. Prendi i CVE di cui sei preoccupato e puoi cercarli e vedere cosa hanno fatto. Tuttavia, la maggior parte dei venditori non è organizzata. (Vedi anche Ciclo di vita di una vulnerabilità legata alla sicurezza ) .
Alcuni venditori hanno anche l'abitudine di rilasciare determinate correzioni solo per pagare i clienti di supporto, a volte anche solo su richiesta specifica. Puoi immaginare come questo complica questa ricerca.
Inference
Poiché MITER cerca di rintracciare gli annunci dei venditori relativi ai CVE, potrebbe essere possibile determinare quali problemi un fornitore ha affrontato osservando i riferimenti "Fonte esterna" all'interno di un CVE. Ad esempio, leggendo i dettagli per CVE-2015-0202 , abbiamo può vedere che OpenSuSE e Mandriva hanno collegamenti. Il collegamento OpenSuSE descrive la versione aggiornata dell'aggiornamento (e il collegamento Mandriva è rotto). Red Hat non è collegato qui; come abbiamo visto sopra, non sono vulnerabili, quindi l'assenza da questo elenco non è una prova di vulnerabilità.
MITER mantiene anche CVE Reference Key / Maps . Ad esempio, il Map for Source MS , fornisce una mappa molto accurata e organizzata di CVE alle patch di Microsoft. Ma, come con tutto il resto,
Note that the list of references may not be complete.
Scanner per le vulnerabilità
Affidarsi alle persone per mantenere i database aggiornati e pubblicati è, dobbiamo farlo, fallibile. Ecco perché utilizziamo gli scanner di vulnerabilità per verificare. Gli scanner di vulnerabilità sono anche fallibili - in particolare, i test eliminati dalle informazioni limitate (come gli annunci sulla versione del banner di servizio) spesso falliscono. Diciamo che OpenSSH-2.3.4 è vulnerabile a CVE-2002-1234, che è patchato in OpenSSH-3.4.5. Red Hat può prendere la patch di sicurezza specifica per tale vulnerabilità e backport, creando OpenSSH-2.3.4p2, che si annuncia ancora come OpenSSH-2.3.4 nel banner di servizio. Poiché lo scanner sta eliminando la versione e non sta effettivamente esercitando il bug per dimostrare che è lì, considererà il sistema vulnerabile.
Quando lo scanner fa ciò, dobbiamo cercare il problema con tutti gli elementi trovati sopra e dimostrare che non è realmente vulnerabile.
Riepilogo
Per ovvi motivi, i venditori non forniscono un elenco ordinato di cose che hanno scelto di non applicare. Onestamente, se gliene importa abbastanza da rintracciarlo, probabilmente si preoccuperebbero abbastanza anche di risolvere i problemi. Ma, di per sé, tutto ciò che una tale lista farebbe è renderli esplicitamente negativi, quindi non c'è molta motivazione a farlo.
Possiamo accontentarci di ciò che forniscono e possiamo dedurre le cose quando effettuiamo ricerche e non siamo in grado di trovare la prova della disponibilità delle patch. Queste non sono soluzioni esatte. Detto questo, ricordo la vita prima che iniziasse il database CVE, e stiamo molto meglio di prima.