L'articolo collegato sta parlando in termini molto generali perché si tratta di un'implementazione generica di riferimento debole nei garbage collector. Stanno affermando i potenziali problemi di riservatezza perché, al livello astratto su cui stanno lavorando, i tipi specifici di attacco di canale laterale che possono essere presentati dipendono interamente da implementazioni individuali.
Per cominciare, è importante capire quali sono i riferimenti deboli.
In un sistema garbage collection, il GC ha il compito di eliminare gli oggetti che non sono più in uso dal programma. Il rilevamento della presenza di un oggetto è spesso implementato tramite conteggio dei riferimenti , in cui il programma memorizza i metadati di riferimento accanto all'oggetto per aiutare il GC, incrementando e decrementando il contatore di riferimento man mano che si consumano oggetti e ambiti entrano e superano la loro durata. I tradizionali tipi di riferimento sono solitamente chiamati riferimenti forti .
Uno svantaggio del referenziamento strong è che non è possibile osservare un oggetto senza impedire al GC di eliminarlo. Ad esempio, è possibile che si desideri fornire comandi di debug interni che visualizzino le informazioni sugli oggetti allocati all'interno di una raccolta, senza creare un riferimento sicuro che fa sì che l'oggetto rimanga permanentemente nell'heap fino alla chiusura del programma. È qui che i riferimenti deboli sono utili: indicano al GC che il programma è ancora interessato all'oggetto, ma che non è strettamente necessario all'oggetto per rimanere. Ancora più importante, implementano una procedura mediante la quale l'applicazione può controllare (o essere notificato) se il GC ha rimosso l'oggetto e molto probabilmente alcuni meccanismi di blocco che assicurano che il GC non possa rimuovere l'oggetto mentre l'esecuzione del codice è direttamente operativo sull'oggetto .
L'implementazione specifica di un riferimento debole ricade sull'architettura di memoria generale e sui paradigmi di tipo del linguaggio, e il GC stesso è spesso considerato una black-box. Affidarsi a comportamenti specifici del GC, al di fuori del comportamento concreto documentato, è una cattiva pratica per il codice utente. Tuttavia, come attaccante in uno scenario specifico, hai il vantaggio di essere in grado di studiare le parti interne dell'implementazione specifica in uso e usarle a tuo vantaggio.
Come esempio teorico, diciamo che c'è un GC il cui processo di smaltimento per oggetti debolmente referenziati funziona come segue:
- C'è una pressione di memoria?
- Hai eliminato tutti gli oggetti con riferimenti zero, deboli o altrimenti?
- C'è ancora pressione di memoria?
- Assegna la priorità agli oggetti a cui non hai avuto accesso per un lungo periodo.
- Assegna la priorità agli oggetti che hanno meno riferimenti deboli.
- Assegna la priorità agli oggetti di dimensioni maggiori.
Ora, se un utente malintenzionato può rilevare che un oggetto specifico è stato eliminato (alcuni GC consentono il codice di finalizzazione definito dall'utente, che potrebbe esternare l'evento esternamente in qualche modo), allora saprebbero che c'era pressione di memoria, altri oggetti potrebbe essere stato eliminato anche dall'heap, l'oggetto che conoscevano era probabilmente non accessibile per un po ', probabilmente aveva solo uno o due riferimenti deboli, e potrebbe essere più grande di altri sullo heap.
Potrebbero essere informazioni molto utili per una serie di attacchi a canali laterali, o anche per coordinare altri tipi di attacco come gli attacchi a tempo. Potrebbe anche essere utile se compreso nel contesto di un'applicazione specifica, ad es. se un oggetto debolmente referenziato viene solo continuamente consultato mentre l'utente è presente nel sistema, la sua eliminazione potrebbe indicare che l'utente non è nella loro stazione.
La cosa importante da tenere a mente, qui, è che le vulnerabilità sono teoriche e l'articolo sta semplicemente cercando di convincere gli implementatori di GC a tenere a mente questi problemi quando progettano funzionalità di riferimento debole.