I gestori di password perdono informazioni con la memoria di scambio?

10

Il post Come trovare le password in memoria ( password manager) concluso, che le password sono visibili in chiaro se accedi a un sito web. I gestori di password tendono a memorizzare le password crittografate in memoria, ma hanno bisogno di decrittografarle per poter accedere.

È necessario un dump della memoria, che la macchina di destinazione sia in esecuzione e che la vittima esegua l'accesso a un account. La password potrebbe essere esposta in testo semplice e potrebbe essere creato un dump della memoria (con un attacco di avvio a freddo o in qualche altro modo).

Ma per quanto riguarda lo swap? Di solito viene utilizzato, se la RAM esaurisce la capacità e la memoria viene esternalizzata su disco. Le capacità esternalizzate potrebbero contenere una password non crittografata, che verrà memorizzata "persistentemente" su disco fino a quando non verrà sovrascritta. Con un po 'di fortuna, un utente malintenzionato potrebbe analizzare lo scambio di un computer in un secondo momento senza il requisito, ovvero che la destinazione utilizza il computer.

Quindi, uno swap è vulnerabile a questo tipo di attacco?

Dopo aver letto le risposte ho fatto un po 'di ulteriori ricerche e ho trovato un post simile su Askubuntu che suggerisce di crittografare la partizione di swap. Ciò dovrebbe evitare i problemi relativi alle informazioni trapelate nella memoria di scambio.

    
posta user3147268 10.08.2015 - 09:45
fonte

2 risposte

6

Come ho già indicato in il mio commento precedente , questo attacco è stato previsto e già neutralizzato (dalla maggior parte della crittografia utilizzando le applicazioni).

Il modo in cui lo fai è che tu (lo sviluppatore) dici al sistema operativo (OS) di non scambiare questa particolare sezione della memoria. Il sistema operativo generalmente onorerà questo e "farà una nota" da qualche parte nel gestore della memoria per non scambiarlo. Tuttavia, anche questa area contrassegnata potrebbe essere sostituita (se troppo dati sono dichiarati "non riscrivibili" o un programma in modalità kernel richiede "troppa" memoria), quindi è meglio che non fare nulla (e lasciarlo essere non riscrivibile) ma non è ancora perfetto e ti dice di non contrassegnare tutto non cancellabile.

Dato che sei preoccupato di scambiare dati segreti su disco potresti essere preoccupato anche dello stato di ibernazione di molti OS, dove in realtà scrivi la RAM corrente completa sul disco in modo da poter avviare più veloce in un secondo momento e può riprendere il tuo lavoro. Questo scenario di attacco è considerato meno comunemente, ma dovrebbe essere contrastato da un trattamento accurato (- > cancella tutte le chiavi / password in chiaro di sospensione / ibernazione) e la crittografia dei dati appropriata.

Come richiesto nei commenti all'altra domanda, fornirò anche rapidamente (alcuni) una panoramica su dove verificare se il programma usato (open-source) è vulnerabile.

Windows: è necessario esaminare la porzione di memoria (gestione password) del codice e cercare specificamente VirtualLock() e VirtualUnlock

Sistemi simil-Unix: ispeziona la stessa parte del codice di Windows, ma ora controlla mlock() e munlock() . Cerca anche mlockall() in qualsiasi momento nel codice poiché questo blocca globalmente la memoria nella RAM.

    
risposta data 10.08.2015 - 16:51
fonte
1

Hai ragione su questa ipotesi: un utente malintenzionato potrebbe analizzare lo scambio di un disco rigido cercando le password. È per questo motivo che i gestori di password scritti in modo corretto assicurano che la password sia sempre conservata nella RAM e non venga mai scambiata nella memoria virtuale.

    
risposta data 10.08.2015 - 11:41
fonte

Leggi altre domande sui tag