Esiste un processo documentato per il rilascio di informazioni ufficiali per vulnerabilità soggette a embargo nel sistema CVE?

8

Esiste un processo documentato per il rilascio di informazioni ufficiali per le vulnerabilità soggette a embargo nel sistema CVE (Common Vulnerabilities and Exposures)?

Se esiste un tale processo, come affrontare situazioni come la recente vulnerabilità del page-table di Intel Kernel, in cui la vulnerabilità è già stata divulgata pubblicamente tramite canali non ufficiali, e un exploit proof-of-concept pubblicamente disponibile è già stato documentato ?

Ho tentato di stimare l'impatto della recente vulnerabilità della tabella di pagina del kernel Intel sottoposta a embargo menzionata in questa domanda . Come menzionato in questo post, questa vulnerabilità ha numerosi riferimenti in social media account risalenti al 4 novembre , forums , molte notizie siti , e patch per Linux (4 dicembre) sono stati persino benchmark . Esiste anche un articolo di Wikipedia su di esso, così come documentazione pubblica che risale a 6 mesi. La mancanza di informazioni ufficiali su questa vulnerabilità e l'intenso controllo pubblico del difetto hardware e del work inund del software in sospeso hanno portato alla pubblicazione di una grande quantità di informazioni contrastanti.

Con tutte queste informazioni non ufficiali disponibili, non ho ancora incontrato un singolo identificatore associato alla vulnerabilità che fornisce un riferimento comune per le patch e le discussioni. Sappiamo che esiste un numero CVE, ma dal momento che è embargo, né il numero né alcuna documentazione ufficiale è stata rilasciata al pubblico. Gli aggiornamenti Linux contenenti patch per questa vulnerabilità saranno rilasciati da Amazon non appena il 5 gennaio e uno simile da Microsoft è atteso per il 9 gennaio, tuttavia non ci sono informazioni ufficiali disponibili, il che comporterà la distribuzione di questi aggiornamenti da parte di molte organizzazioni (tra cui il mio) basato solo su informazioni selvaggiamente conflittuali riguardanti la causa, mentre si è verificato un calo prestazionale del 30% a più livelli di molti stack software.

Comprendo l'idea alla base dell'embargo - divulgare troppe informazioni prima che una soluzione o soluzione alternativa sia disponibile darà un vantaggio a individui o organizzazioni che scrivono exploit. Tuttavia, la quantità di informazioni non ufficiali già disponibili sembra aver reso l'embargo un punto controverso, considerando che ci sono già exploit proof-of-concept documentato .

    
posta vallismortis 03.01.2018 - 19:23
fonte

1 risposta

2

La rivelazione di Google (s) di ieri sera (3 gennaio) contiene un breve riassunto della fine dell'embargo, che era originariamente previsto per il 9 gennaio, ma è stato spostato in avanti di una settimana a causa della quantità di informazioni pubbliche già disponibili.

Da " Lettura della memoria privilegiata con un canale laterale " :

We [Google] reported this issue to Intel, AMD and ARM on 2017-06-01.

Da " Vulnerabilità della CPU di oggi: cosa è necessario sapere ":

We are posting before an originally coordinated disclosure date of January 9, 2018 because of existing public reports and growing speculation in the press and security research community about the issue, which raises the risk of exploitation. The full Project Zero report is forthcoming (update: this has been published; see above).

Gli identificatori e le divulgazioni CVE sono stati resi disponibili al pubblico non appena l'embargo è terminato:

Attacco di fusione

Mitra CVE-2017-5754 e NIST NVD CVE-2017-5754

Spectre Attack

Mitra CVE-2017-5753 e NIST NVD CVE-2017-5753

Mitra CVE-2017-5715 e NIST NVD CVE-2017-5715

Gli identificatori CVE sono stati resi pubblici con la fine dell'embargo, che ha servito da segnaposto nei database CVE e NVD per diverse ore. A partire dal 4 gennaio, la divulgazione è stata resa pubblica tramite tali siti.

    
risposta data 04.01.2018 - 15:58
fonte

Leggi altre domande sui tag