Come posso garantire che l'intera RAM sia stata azzerata? Un riavvio (Power On Self Test) cancella tutta la memoria prima dell'avvio del sistema? O un kernel Linux azzera la memoria prima di procedere?
Ho familiarità con attacco di avvio a freddo e contromisura TRESOR . Sono solo interessato ad altri modi meno elaborati di cancellare la memoria.
Durante il POST , il BIOS esegue tradizionalmente un "test della memoria" che comporta la scrittura e la rilettura l'intera RAM fisica. Tuttavia, questo processo può richiedere una quantità di tempo non trascurabile, ed è piuttosto brutto nel rilevare una cattiva memoria (rileva in modo affidabile solo molto cattiva memoria) quindi è disabilitato in molti casi (dal produttore del computer) o l'utente). Pertanto, si deve presumere che gli scarti del contenuto della RAM prima dell'ultimo avvio possano ancora persistere; la quantità di dati rimane quindi dipende dalla tecnologia RAM, dal tempo di spegnimento prima del nuovo avvio e dalla temperatura.
Il kernel Linux, come la maggior parte degli altri sistemi operativi moderni (incluso Windows, escludendo Windows dalla riga "95"), azzera le pagine RAM prima di passarle alle applicazioni. Pertanto, mentre il contenuto della RAM fisica potrebbe contenere resti interessanti di dati passati, questo è accessibile solo al codice del kernel; userland vede solo zeri.
Su Tails lo fa!
Oltre a questo non sono a conoscenza di nessun altro sistema operativo popolare che lo faccia per impostazione predefinita, quindi se qualcuno ha inserito la tua RAM si blocca in qualche tipo di sistema operativo scritto allo scopo di spiare i tuoi dati (probabilmente dovrebbe essere un kernel essenzialmente su misura per evitare qualsiasi operazione di scrittura su RAM) sarebbero in grado di ottenere tutta quella memoria dolce e succosa.
Grazie a Thomas Pornin per il suggerimento che le applicazioni in modalità utente non possono accedere alla RAM raw.
Riavvia No, non più.
Oggi i sistemi sono progettati per essere in grado di sostenere il contenuto della RAM molto bene per stand-by / sleet / hibernate o qualsiasi tipo di stati sospesi e per altri scopi come dischi RAM persistenti. A meno che il software non faccia cose speciali per cancellare il contenuto della RAM (come TrueCrypt se esegui TrueCrypt / Wipecache), i dati rimarranno lì fino a quando non verranno sovrascritti.
Come per una procedura di disconnect-from-power, allora sì, il contenuto della RAM è chiaro, abbastanza veloce per DDR3 e superiore, quindi diventa praticamente vuoto a meno che il sistema non sia progettato con una sorta di batteria di backup integrata (come per alcuni sistemi o server di archiviazione).
Ora, se vuoi intenzionalmente cancellare la RAM senza ottenere mezzi barbarici come scollegare, puoi avviare un memtest e lo pulirà molto bene per te.
Ho usato anche su sistemi operativi precedenti un modo diverso per scopi di test: ho un file di test (con dati casuali o solo un carattere ripetuto), grande quanto la RAM del sistema. Lo apro per la modifica con un editor che carica l'intero file nella RAM. A un certo punto, ci sarà un errore out-of-RAM. Chiudo l'editor e continuo il mio lavoro.
La memoria non viene cancellata al riavvio (testata su Macbook). Puoi controllare banalmente questo sotto Linux eseguendo un programma, riavviandolo in modo che il programma non sia più in esecuzione, e poi grep in /dev/mem per l'hash delle stringhe contenute nella memoria del programma. Ad esempio:
Accedi come root quindi
# sums=$(strings /dev/mem | while read s; do echo $s | sha256sum; done)
# echo "${sums}" | grep 79b4f11b6ccf3a7c397fbfd032672c65d825bdb38eae1aa445183b0b3934be6b
Questo calcola il checksum sha256 di tutte le stringhe in memoria. I checksum sono quindi grepped per il checksum sha256 prodotto da echo THUNAR_ZOOM_LEVEL | sha256sum . THUNAR_ZOOM_LEVEL è una stringa di configurazione da / usr / bin / thunar (thunar è un file manager per il desktop XFCE). Dato che questo avvio Linux era in modalità utente singolo, Xorg non sarà in esecuzione e nessuna app X sarà stata avviata, quindi questa stringa non proviene dal boot corrente. Le stringhe dell'applicazione Xorg in memoria sono state mantenute dal precedente avvio.
Se scarichi /dev/mem con dd o esegui strings su di esso vedrai la memoria di tutti i programmi grafici che erano in esecuzione nella GUI - programmi che erano in esecuzione prima del riavvio ma non sono in esecuzione in modalità utente singolo.
Sulle macchine virtuali sembra che la memoria non sia stata cancellata. In IncludeOS (includeos.org) lo usiamo per archiviare i dati di crash in memoria (poiché lo stack IP e il sistema IO potrebbero non essere funzionanti) e raccogliere il rapporto sugli arresti anomali dopo aver riavviato il sistema.
Lo abbiamo testato su qemu / kvm e Vmware ESXi. Non abbiamo testato su bare metal.
Leggi altre domande sui tag memory data-leakage