Sono utili, non sono solo utili per la creazione di exploit. Non sono utili per determinare quanto sia buggy un software sia per questo ... Il numero di CVE non ha una strong correlazione con la qualità del codice.

Per cosa sono utili, sta determinando, come amministratore, se le versioni di un determinato pacchetto software che stai usando sono state patchate per specifici exploit noti, e il potenziale impatto degli exploit che sono stati scoperti In questo modo, possono alimentare direttamente un processo di gestione delle vulnerabilità come uno dei tanti strumenti che è possibile utilizzare per garantire che la propria organizzazione gestisca correttamente i rischi di sicurezza del software.

Il caso d'uso principale per CVE è di avere identificatori univoci per le vulnerabilità del software. È non è un buon strumento per misurare la sicurezza generale di un prodotto e non ti aiuterà con l'analisi approfondita di un bug.

Dovresti pensare a CVE come a un dizionario piuttosto che a un database che assegna nomi standard alle vulnerabilità in modo che tu possa riferirti in modo inequivocabile su diversi sistemi. Non commettere l'errore di presumere che una voce CVE fornisca una spiegazione completa di una vulnerabilità o una stima accurata dell'impatto.

La pagina About CVE rende abbastanza chiaro che l'attenzione è incentrata sulla standardizzazione :

CVE is:

• One name for one vulnerability or exposure
• One standardized description for each vulnerability or exposure
• A dictionary rather than a database
• How disparate databases and tools can "speak" the same language
• The way to interoperability and better security coverage
• A basis for evaluation among tools and databases

[...]

Quindi CVE non intende essere un database completo di tutte le vulnerabilità conosciute in qualsiasi prodotto, in quanto le voci non sono né verificate da terzi né necessariamente completate. È principalmente utile come una panoramica e per avere un identificatore univoco che puoi utilizzare per risolvere il bug in una patch o in un write-up.

I CVE sono utili in diversi modi.

In primo luogo, e forse la cosa più importante, forniscono un termine comune per una particolare vulnerabilità. Ciò semplifica il fatto che quando qualcuno dice "hai visto la vulnerabilità di Android", stai parlando della vulnerabilità di stessa di Android. Inoltre semplifica enormemente la ricerca di ulteriori informazioni sul problema.

In secondo luogo, quando fai clic sulla pagina NIST sulla vulnerabilità , contiene CVSS informazioni che, se hai familiarità con la lettura della notazione, ti consentono di ottenere una rapida panoramica di quanto sia fondamentale per te correggere la vulnerabilità nel tuo ambiente.

Come già detto, sono utili ... dipende solo da quello che vuoi fare. Se stai facendo audit di sicurezza, che è il modo in cui affronterò la mia risposta, avere un punto di partenza è importante. Eseguire qualcosa come Nessus o OpenVAS ti dirà che un particolare CVE è correlato con un host. Da lì, dovrai cercare se ci sono degli exploit disponibili usando qualcosa come exploit-db.com . Gli exploit non sono sempre elencati con CVE, quindi è necessaria una due diligence.

Per me, i CVE sono un po 'come i termini del dizionario. È pensato per essere in grado di comunicare facilmente ciò che qualcosa è tramite un'enumerazione comune.

Puoi leggere di più sul motivo per cui sono scritti in questo modo al link

Un buon CVE è quello relativo a OpenSSL: link

La descrizione è breve ma la pagina rimanda a riferimenti pertinenti che si espandono ulteriormente sul CVE.

Nel CVE che stai usando come esempio c'è un link al bollettino sulla sicurezza di Android che ospita più informazioni e Focus sulla sicurezza (anche se non ne parla molto). Se è disponibile un exploit, è probabile che non sia condiviso.

I CVE sono utili per tutti gli attori della catena del software (sviluppatori, amministratori di sistema, clienti ...) per decidere se intraprendere o meno un'azione sul software esistente. La dimostrazione dei concetti viene deliberatamente cancellata perché, come dimostrerò, ci vuole molto tempo per applicare le installazioni reali .

In un mondo teorico, le patch vengono distribuite immediatamente a tutti i dispositivi. Ciò garantisce che tutti i dispositivi siano riparati e protetti. Questo è impossibile.

Scegli Android ...

• T0: una vulnerabilità nel kernel di Linux, che interessa il kernel di Android, viene trovata e patchata
• T1: Google aggiusta AOSP e rilascia la patch
• T2: i produttori di dispositivi mobili (ad esempio LG, Motorola, Samsung) ricevono la patch e la applicano alla build personalizzata
• T3: la patch è consegnata OTA ai consumatori
• T4: un'azienda con migliaia di dispositivi aziendali Android dello stesso produttore distribuisce l'aggiornamento ai dispositivi di lavoro

Scegli Apache ...

Questo è simile a un caso accaduto durante il mio lavoro

• T0: una vulnerabilità in Apache viene trovata e patchata, Apache viene rilasciato
• T1: una grande azienda che utilizza Apache per molte applicazioni installate internall su una varietà di server pianifica l'aggiornamento
• Da T2 a T100: tutte le istanze di Apache vengono aggiornate sui sistemi aziendali, coinvolgendo fornitori e manager per soddisfare e pianificare un piano di test

In breve

I CVE sono utili per determinare "quanti anni" e "quanto è rischioso" un software. Esaminando la gravità e i componenti interessati, il personale IT può decidere se, ad es., Non eseguire l'upgrade per ora, eseguire immediatamente l'aggiornamento, applicare ulteriori misure di sicurezza temporanee (ad esempio firewalling, proxy).

Nel mondo aziendale esiste una intrinseca lentezza nell'aggiornamento del software. Vedo banche che eseguono Java < = 1.5 (di nuovo, non più tardi di 1.5 ) perché le versioni successive non sono state certificate e Java 1.7 è già alla fine. Sappiamo che le aziende eseguono ancora XP perché non sanno se tutte le loro basi software esistenti girano su Windows 7, non osano nemmeno provare 10.

Un CVE severo, secondo la mia esperienza, può essere la ragione per dare la priorità a un aggiornamento del software in uno scenario aziendale strutturato.