Perché e dove è stato reso pubblico Meltdown prima della pianificazione per la prima volta?

4

In origine, Meltdown e Spectre avevano una data di divulgazione coordinata del 9 gennaio 2018. Alcuni venditori si stavano preparando a rilasciare correzioni in quel momento e furono colti di sorpresa quando le vulnerabilità furono rese pubbliche in precedenza (come descritto qui , ad esempio). Ma perché sono stati resi pubblici in anticipo e dove?

Il primo riferimento a queste vulnerabilità che ho trovato è questo articolo dal registro , pubblicato il 2 gennaio. Ma non menziona alcuna fonte diversa da:

However, some details of the flaw have surfaced, and so this is what we know.

Sappiamo dove questi "dettagli" sono emersi per la prima volta e perché sono stati resi pubblici in vista della data di divulgazione coordinata?

    
posta Zoltan 09.01.2018 - 10:12
fonte

2 risposte

6

Ho seguito le notizie di questi attacchi con molto interesse a partire dal 3 gennaio, e ho fatto un po 'di ricerche per vedere cos'altro avevano detto la gente prima della divulgazione.

L'embargo è stato ufficialmente rotto il 3 gennaio da questo post di Google, seguito a breve da un insieme di dettagli tecnici nel loro Post di Project Zero .

In quel primo collegamento giustificano la violazione dell'embargo dicendo: "Pubblicheremo prima di una data di divulgazione originariamente coordinata del 9 gennaio 2018 a causa di rapporti pubblici esistenti e di crescenti speculazioni sulla stampa e sulla comunità di ricerca sulla sicurezza problema, che aumenta il rischio di sfruttamento. "

C'erano un numero di rapporti che un osservatore consapevole avrebbe potuto rilevare prima di quella data. La più grande "pistola fumante" per un exploit speculativo di esecuzione (di cui sono a conoscenza) è stata fatta quando uno sviluppatore AMD ha presentato una patch di Linux su 26 Dicembre , che è legata in questo articolo si fornisce. Per quanto ne so, è la prima volta che un rapporto pubblico collega direttamente i riferimenti alla memoria speculativa a un possibile attacco e patchset. Prima di questo un articolo di LWN del 20 dicembre ha suggerito che il patchest dell'isolamento della tabella di pagina stava effettivamente affrontando un difetto di sicurezza più profondo , ma nessun riferimento specifico all'esecuzione speculativa è la fonte del problema.

Le persone hanno iniziato a prestare attenzione il 28 al 29 dicembre dopo che le patch di isolamento della tabella di pagina sono state unite nel kernel da Linus . Un cambiamento di questa portata richiede di solito molto più tempo per essere applicato al kernel principale, quindi questo essenzialmente ha annunciato al mondo che c'era effettivamente una vulnerabilità soggetta a embargo.

Internet ha iniziato a scoppiare il 30 dicembre e il 1 ° gennaio. grsecurity su Twitter era convinto che ci fosse un dell'embargo almeno fin dal 28, e il 30 osservata al mondo che c'erano commenti sul codice sorgente mancanti nel set di patch di Linux . python dolcezza su Tumblr previsto con precisione il 1 gennaio che si trattava di una vulnerabilità basata sull'hardware in x86 che poteva eseguire letture di memoria non privilegiate e ipotizzava il possibile attacco dell'hypervisor basato sulla presenza di dipendenti di Amazon e di Google in fase di loop.

Quindi, naturalmente, il Registro ha pubblicato il suo pezzo il 2 gennaio e l'intero mondo è stato collegato. L'articolo faceva riferimento alla patch del 26 dicembre di AMD e collegava l'esecuzione speculativa alla vulnerabilità non divulgata.

C'è un crescente interesse nella comunità di ricerca sulla sicurezza riguardo alla vulnerabilità delle moderne microarchitetture. Il Spectre paper cita non meno di 12 lavori su perdite di dati dall'interno del processore o cache L1, e lavori recenti dal 2016 sullo sfruttamento i predittori di ramo per aggirare la randomizzazione dello spazio degli indirizzi hanno probabilmente posto le basi per Spectre. il blog di Anders Fogh delineato alcune tecniche di base per la attacchi alla fine dello scorso luglio ma ha riportato un risultato negativo. Se lanci Fogh lì, sono tre gruppi separati che trovano e segnalano in modo indipendente queste vulnerabilità specifiche entro un anno.

La vulnerabilità di Spectre in particolare è un grosso problema, il che significa che ne parleranno per molto, molto tempo ancora. La mia ipotesi è che parte del desiderio di rivelare presto fosse quello di assicurarsi che rivendicassero il credito dov'era dovuto. Immagina se fossi seduto su una vulnerabilità che cambiava il gioco. Sai che almeno un altro gruppo ha già scoperto in modo indipendente la tua vulnerabilità, e se sei aggiornato sui tuoi blog sai che Fogh ha investigato lo stesso. Un'improvvisa serie di attività di stampa ti spinge a pensare che una quarta persona abbia scoperto e stia per rivelare la stessa vulnerabilità su cui eri stato seduto per un anno!

Ciò che ha causato in modo specifico il team di Google di violare l'embargo non lo sapremo. L'articolo del registro è il candidato più ovvio, ma il gatto è stato davvero fuori dal sacco una volta che le patch di isolamento del tavolo di pagina hanno iniziato a muoversi all'inizio di dicembre.

    
risposta data 09.01.2018 - 21:08
fonte
3

L'articolo iniziale del registro non ha rilasciato dettagli esatti su come funzionavano gli exploit. La versione che hai collegato elenca diverse fonti tra cui la mailing list del kernel di Linux, la fonte di Linux, il blog di Anders Fogh (per un problema estremamente simile).

In quel momento le patch di Linux sono state rilasciate pubblicamente e le e-mail relative ad esse erano sulle mailing list di Linux .

Il registro potrebbe essere comparso su uno di questi o essere stato contattato da uno qualsiasi di un numero molto elevato di persone nelle società e organizzazioni open source che sono state contattate entro il periodo di embargo.

La ragione per cui gli embargo sono un argomento a due lati. Durante il periodo di embargo non puoi essere certo che le parti cattive non stiano già sfruttando l'attacco in natura. Nel frattempo, sai per certo che ci sono un gran numero di parti vulnerabili che hai deliberatamente scelto di non far sapere in modo che possano prendere provvedimenti per mitigare / ridurre l'impatto.

O il punto di vista scettico - qualcuno si è offerto di venderlo al registro e sapevano quanto sarebbero enormi le entrate pubblicitarie.

    
risposta data 09.01.2018 - 10:47
fonte

Leggi altre domande sui tag