it-swarm.dev

Perché crittografare i dati in memoria?

Ho visto che KeePass non solo crittografa il suo file-database-password, ma può anche crittografare le password in memoria. Questo è solo un esempio. Sto pensando a un nuovo progetto che tratta dati sensibili/personali e ora mi chiedo se dovrei crittografare anche i dati conservati in memoria. Questo progetto verrebbe implementato con Java SE e un altro Android. In questo caso speciale non ci saranno dati memorizzati nel cloud o su un server. I dati da Android verranno importati dall'applicazione Java SE Desktop tramite connessione via cavo.

Ma perché è assolutamente necessario? I moderni sistemi operativi non funzionano con la gestione della memoria virtuale in modo che non sia possibile per i processi spazio utente/modalità utente accedere alla memoria di altri processi?

È solo un'altra linea di difesa se esiste una vulnerabilità del sistema operativo che rende possibile l'accesso alla memoria esterna? In tal caso, penso che sarebbe molto più semplice rubare il file di dati e utilizzare un key-logger per catturare la password immessa dall'utente invece di rubare i dati attraverso l'accesso alla memoria.

26
user573215

In un mondo perfetto, hai ragione: non dovrebbe avere senso mantenere i dati crittografati nella RAM. Il sistema operativo dovrebbe mantenere una forte separazione tra i processi, deselezionare RAM quando viene riallocato a un altro processo e, se il modello di attacco consente a un utente malintenzionato di rubare il dispositivo in seguito e fare analisi del disco rigido, crittografare il swap (o non utilizzare affatto swap, il che potrebbe avere più senso per un dispositivo con memoria basata su Flash).

In un mondo realistico, in cui i sistemi operativi e l'amministrazione del sistema sono sforzi umani e quindi intrinsecamente non perfetti, potresti voler aggiungere alcune garanzie, incluso mantenere i dati crittografati in RAM e istruire il sistema operativo non per scrivere i dati nello spazio di swap (su sistemi simili a Unix, questo viene fatto con mlock()). Tuttavia, questo crittografa-in- Le cose RAM sono più un rituale psicologico che una vera difesa; la sua principale virtù è nel far sentire meglio lo sviluppatore.

Non preoccuparti di farlo in Java, comunque. garbage collector copierà gli oggetti in RAM in modo trasparente (fa parte degli algoritmi GC più efficienti e non è possibile prevenirlo), quindi nessun livello di crittografia dell'applicazione garantire che non esistano versioni chiare delle chiavi in ​​RAM in qualsiasi momento.

27
Thomas Pornin

I moderni sistemi operativi funzionano con la gestione della memoria virtuale in modo che per impostazione predefinita non sia possibile per i processi spazio utente/modalità utente accedere direttamente alla memoria di altri processi.

Ma in Windows (non so se questo vale anche per Linux) ci sono interfacce che consentono agli utenti standard di accedere alla memoria di processo di altri processi in esecuzione con le stesse credenziali.

Esistono molti programmi che utilizzano questa interfaccia. Un esempio molto semplice è HxD - un editor esadecimale freeware che consente di visualizzare e persino modificare la memoria di processo di altri processi.

9
Robert

La memoria può diventare visibile ad altri processi mediante:

  1. essere disponibile una volta che il processo originale che lo utilizza lo ha restituito al sistema operativo. La memoria non viene cancellata e un processo successivo potrebbe eseguire una malloc() e recuperare informazioni appartenenti a un processo precedentemente in esecuzione (nota capitolo 8 dei Driver di dispositivo Linux - in particolare la nota a piè di pagina sul primo pagina)
  2. pagine scambiate su disco dal sistema operativo. Questi possono quindi diventare disponibili per un processo che guarda il disco/archiviazione.

Di conseguenza, la memoria non crittografata può diventare visibile ad altri processi.

Questo è un link molto interessante e nota questa citazione:

Questa volatilità dipende in gran parte dal computer in questione, tuttavia, poiché quando un computer non sta eseguendo alcuna operazione la memoria anonima può persistere per lunghi periodi di tempo. Ad esempio in alcuni computer le password e altri dati precalcolati sono stati facilmente recuperati giorni dopo essere stati digitati o caricati in memoria

7
Brian Agnew

Ci sono alcuni problemi specifici del Java che devi considerare. È una pratica normale che si facciano cumuli di JVM se si presenta un problema tecnico. un'app che ha anche un'interfaccia utente dedicata per questo. Questo potrebbe essere incredibilmente prezioso, ad esempio per trovare perdite di memoria. E certo - sì - le informazioni sensibili vanno nel dump. Quindi, se qualcuno rompe l'app (ad esempio, ignora l'accesso con un SQL Iniezione :)) ...: X. O se l'utente amministrativo è una persona curiosa ...: X

So che questo non dovrebbe accadere nel "mondo ideale".

Inoltre, è possibile configurare JVM per eseguire il dump delle eccezioni di memoria insufficiente. Da Java 1.4 questo potrebbe assomigliare a questo:

-XX:-HeapDumpOnOutOfMemoryError  -XX:HeapDumpPath=<path to dump file>

Un utente malintenzionato può trovare un exploit che fa arrestare l'app con memoria insufficiente e può trovare un altro exploit (ad esempio un bug di attraversamento del percorso del file) per rubare il dump!

L'altra cosa a cui dovresti pensare è che alcuni dati sensibili dovranno in qualche modo farsi strada nella tua app. Quindi in certi momenti lo avrai in memoria. C'è poco o niente che puoi fare al riguardo. Ma quello che puoi fare è pulirlo più velocemente. Ad esempio, prendere una password utente. Se lo memorizzi in un'istanza String, allora non hai molto controllo su quando sarà la garbage collection. Pertanto, in genere le API Nice elaborano tali dati in array di caratteri (char []) che possono essere azzerati dopo l'uso.

2
Lachezar Balev

Google ha un exploit chiamato RowHammer che consente a un utente di leggere il contenuto di RAM adiacente ai dati su cui si sta scrivendo. Crittografia del RAM renderebbe questo exploit molto più difficile.

"Rowhammer" è un problema con alcuni recenti dispositivi DRAM in cui l'accesso ripetuto a una riga di memoria può causare ribaltamenti di bit nelle file adiacenti. Abbiamo testato una selezione di laptop e abbiamo scoperto che un sottoinsieme di essi presentava il problema. Abbiamo creato due exploit di escalation di privilegi di lavoro che utilizzano questo effetto. Un exploit utilizza lanci di bit indotti da Rowhammer per ottenere i privilegi del kernel su Linux x86-64 quando eseguito come un processo userland senza privilegi. Quando eseguito su una macchina vulnerabile al problema del martello pneumatico, il processo è stato in grado di indurre lanci di bit nelle voci della tabella delle pagine (PTE). È stato in grado di utilizzarlo per ottenere l'accesso in scrittura alla propria tabella di pagine e quindi ottenere l'accesso in lettura e scrittura a tutta la memoria fisica.

Non sappiamo con certezza quante macchine sono vulnerabili a questo attacco o quante macchine vulnerabili esistenti sono riparabili. Il nostro exploit utilizza l'istruzione CLFLUSH x86 per generare molti accessi alla DRAM sottostante, ma altre tecniche potrebbero funzionare anche su sistemi non x86.

Ci aspettiamo che il nostro exploit basato su PTE possa essere fatto funzionare su altri sistemi operativi; non è intrinsecamente specifico per Linux. Causare lanci di bit nei PTE è solo una via di sfruttamento; anche altre strade per sfruttare i bit flip possono essere pratiche. L'altro nostro exploit lo dimostra fuggendo dalla sandbox di Native Client.

1

KeePass ha nello specifico un'estensione chrome, quindi altre Chrome potrebbero leggere la stessa memoria utilizzata da KeePass. Le protezioni della memoria del sistema operativo non aiuteranno in questo caso. Da qui la crittografia.

Un'altra famiglia di motivi per la crittografia della memoria, in generale, è perché ci sono attacchi hardware in cui qualcuno può accedere alla memoria:

  • Cold boot attack consente a un utente malintenzionato di riavviare la macchina mantenendo intatta la memoria. Quindi si avviano su un sistema operativo alternativo senza protezione della memoria ed eseguono una scansione.
  • Il blocco di RAM chips li induce a conservare il loro contenuto anche dopo la perdita di potenza. Quindi un hacker con accesso fisico potrebbe rimuovere il RAM e posizionarlo in un contenitore di stoccaggio di azoto liquido, quindi spostare il RAM in un'altra posizione e reinstallarlo ed eseguirne la scansione.
  • Vari bus hardware come PCI e Firewire supportano DMA che consente al dispositivo di accedere direttamente alla memoria. Quindi un hacker potrebbe inserire un dispositivo nella macchina che legge RAM.

Nota a margine: Intel e AMD offrono entrambe RAM come funzionalità ora.

1
Moby Disk

Il motivo per cui sembra una buona idea è che vorrai proteggere i dati dal furto mentre risiedi in memoria. Ciò presuppone che i dati nel database effettivo siano crittografati (come dovrebbero essere tutte le PII) ma che rimangano non crittografati nella memoria mentre vengono elaborati. Ciò sarebbe piuttosto difficile da fare per una serie di ragioni delineate da altri commentatori e introdurrebbe una grande complessità in termini di come le applicazioni funzioneranno con i dati crittografati in memoria.

Ciò che è una soluzione migliore e più fattibile è garantire un controllo di accesso adeguato al database/sistema e anche garantire che il DBMS sia eseguito con un account utente "normale" e non un account elevato come SISTEMA, ecc. Esistono anche controlli investigativi aggiuntivi può mettere in atto uno strumento di monitoraggio DBMS che è possibile configurare per guardare grandi selezioni su tabelle sensibili ecc. e riferire su tutto ciò che è fuori dal comune. In questo modo puoi vedere se c'è qualche selezione o processo che tenta di ottenere grandi quantità di dati.

0
Michael