Bloccare l'indice dell'array - è una buona idea per la mitigazione di Spectre di Javascript?

Question

Bloccare l'indice dell'array - è una buona idea per la mitigazione di Spectre di Javascript?

#1 da (2 voti)

3

Dal Spectre document ho appreso che l'attacco può avere successo perché il compilatore genera un'istruzione di lettura della memoria che fa riferimento a indice di array. E anche se normalmente l'istruzione viene eseguita solo dopo aver controllato l'indice dell'array, l'accesso agli elementi out-of-bounds produce effetti collaterali indesiderati attraverso l'esecuzione speculativa in alcune CPU.

javascript:

  x=array[index];

assembler pseudocode:

  MOV reg,index
  CMP reg,array[length]
  JNC fail
  MOV x,array[reg]
  ...access probe array based on x

Cosa succede se il compilatore è stato modificato per non generare mai indirizzi non validi?

assembler pseudocode:

  MOV reg,index
  CMP reg,array[length]
  JNC fail
  AND reg,array[bit_mask] <---| bit mask of all 1's lower than
  MOV x,array[reg]            |  2*length (might be an object member)
  ...access probe array based on x

In questo modo, per il prezzo di un extra E, l'indirizzo utilizzato nella lettura speculativa è limitato a meno di 2 * lunghezza. Successivamente, per tutti i buffer dell'array, allociamo sempre 2 ^N byte (N > = log ₂ (length)) e l'attacker sarà in grado di sondare il proprio non utilizzato memoria (in alternativa, organizzare le allocazioni di memoria in modo che l'unica memoria disponibile per il test sia il proprio altro buffer).

Questa è una buona idea?

javascript spectre

posta szulat 08.01.2018 - 02:19

fonte

1 risposta

Leggi altre domande sui tag javascript spectre

Anonimizzazione dell'identità dell'utente PHP e MySQL che crittografa i dati che ho bisogno di decodificare a un certo punto

score 2 · Answer 1

Un approccio simile è stato preso dagli sviluppatori WebKit, tra l'altro, per mitigare i possibili effetti di Spectre.

Vedi: "Che spettro e disgelo significano per WebKit" , paragrafo "Mascheramento indice" .

Nota che il mascheramento dell'indice è diverso dalla tua proposta in quanto non richiede di allocare 2 ^N byte per ogni array (nel peggiore dei casi, quasi il doppio di quanto richiesto), quindi esponendo ancora una porzione (piuttosto limitata) di informazioni a un utente malintenzionato, ma riducendo la quantità di dati consentiti a un utente malintenzionato di leggere in generale e di salvare un po 'di memoria per motivi di efficacia. Per gli array di grandi dimensioni, potrebbero fidarsi dell'ASLR, il che rende meno probabile un'assegnazione all'interno della raggiungibilità della maschera indice.

Ciononostante, ciò che potrebbe essere esposto a un utente malintenzionato in questo modo in WebKit dipende dalla sua architettura e dalla base di codice; il tuo potrebbe essere diverso.

Riguardo all'efficacia di allocare quasi il doppio della memoria richiesta nel peggiore dei casi, vale la pena ricordare che il tasso di crescita dell'array ideale è vicino a 1,6 e il fattore di crescita di 2 è ampiamente utilizzato ma molto meno efficace .

Tuttavia, supponendo che Linux, probabilmente c'è un trucco che potrebbe essere usato per ridurre la quantità di memoria che si sta perdendo rimanendo al sicuro dalle letture speculative fuori dai limiti. Puoi provare a scrivere un allocatore personalizzato che, per gli array di dimensioni superiori a 2 * (quest'ultimo è 4K nella maggior parte dei casi, ma in modo più rigoroso, sysconf(SC_PAGE_SIZE) ), analizzerà innanzitutto /proc/self/maps per trovare una regione di memoria non mappata di una dimensione almeno 2 ^N byte, N > = log ₂ (array_length), quindi mappare solo la dimensione richiesta tramite mmap(MAP_FIXED) .

Saranno necessari alcuni lavori successivi per garantire che nessuna memoria venga mappata entro 2 * lunghezza di qualsiasi array assegnato prima, ma questa non è ancora una scienza missilistica.

Le pagine di memoria assegnate e restituite saranno consecutivi nella memoria virtuale, ma non è necessario che siano consecutivi nella memoria fisica, quindi questo approccio non causerebbe la frammentazione della memoria fisica . La successiva frammentazione della memoria virtuale non sarebbe probabilmente un problema su un sistema a 64 bit in tempi brevi, poiché 16 exabyte di memoria indirizzabile totale dovrebbero essere sufficienti per chiunque.

Altri sistemi operativi probabilmente hanno strumenti simili a quelli di Linux.

Riguardo a WebKit, poiché presenta anche altre attenuazioni, che sono, a partire da ora, destinate a essere sufficienti per gli effetti di Spectre stesso, il mascheramento dell'indice è una mitigazione piuttosto eccessiva per loro, e il loro approccio va bene per il loro modello di minaccia rimanente .

Il tuo modello di minaccia, tuttavia, potrebbe essere diverso. Questo è tutto ciò che sappiamo.