Senza mezzi termini, sì, potevano. Questa è la risposta enormemente semplificata.
La risposta più complicata è che devi capire come il tuo sistema operativo gestisce la memoria. Potresti sentire parlare di anelli, livelli di privilegi, ecc. Lasciatemi spiegare brevemente:
- Quando il tuo sistema operativo inizia (superando l'intera cosa a 16-bit del BIOS) ha fondamentalmente un'intera pila di memoria (tutta la tua RAM) con cui lavorare e lo fa in una modalità privilegiata, il che significa che può fare qualunque cosa piace a qualsiasi parte della memoria.
- Tuttavia, architetture x86 dal 1980 - qualcosa prima che io nascessi hanno supportato il concetto di modalità protetta, in cui l'hardware della CPU fornisce meccanismi per consentire al sistema operativo di avviare le applicazioni in modo tale da separare gli indirizzi di memoria.
- Così questa modalità protetta consente al sistema operativo di creare uno spazio di indirizzi virtuali per ogni applicazione. Ciò significa che il concetto di memoria di un'applicazione non è lo stesso degli effettivi indirizzi di memoria fisica e che l'applicazione non ha accesso privilegiato alla memoria. Infatti, alle applicazioni viene direttamente impedito di modificare gli indirizzi di memoria l'uno dell'altro perché non possono vederlo, tranne tramite richieste ben definite al sistema operativo (syscalls) per richieste di cose come la memoria condivisa, dove due i processi condividono uno spazio indirizzo.
(questa è una semplificazione e sto saltando pezzi enormi per brevità, ma questo è il succo - le applicazioni hanno le loro richieste per accedere alla memoria gestita dal sistema operativo e dall'hardware).
Quindi, in teoria, stai bene, giusto? Non tecnicamente vero. Come ho detto, i sistemi operativi forniscono modi ben definiti per accedere alla memoria di altri processi. In termini di possibilità, ecco come potrebbero presentarsi alcuni:
- Se I scarica la memoria dell'applicazione , posso risolvere abbastanza facilmente la password memorizzata.
- Un debugger o un rootkit in stile userland progettato in modo appropriato potrebbe essere in grado di fornirmi l'accesso a tale memoria. Non sono un esperto di tali tecniche, ma so che può essere fatto in determinate circostanze.
- Infine, il sistema operativo potrebbe essere controproducente qui. La memoria virtuale a cui hai accesso ha alcune altre conseguenze. I sistemi operativi lo presentano come virtuale perché scambiano spesso la memoria per garantire che ci sia sufficiente RAM disponibile per le app attualmente in esecuzione. Quindi un attacco interessante potrebbe essere quello di fare in modo che il sistema si scambia, quindi si blocca ed esamina la partizione di swap. Anche il tuo swap è crittografato?
Infine, dovrei sottolineare che se il tuo attaccante sta eseguendo il codice nel kernel tramite un modulo del kernel, il gioco è finito comunque, poiché non c'è nulla che impedisca loro di cercare spazio nella tua memoria per le stringhe ascii.
Tuttavia, per essere realistico:
- Se il tuo kernel è compromesso tramite un rootkit, un keylogger è probabilmente più facile da implementare di qualcosa progettato per analizzare la memoria in termini di acquisizione delle tue password.
- I rootkit in stile userland che coinvolgono i debugger per la valutazione di programmi non progettati per il debug (cioè senza debug di simboli, ecc.) non saranno una cosa facile da implementare, anche se sono teoricamente possibili. Inoltre, non è facile sfruttarlo: tu, l'utente, dovresti essere ingannato nell'eseguire il suddetto editor sotto il debugger che probabilmente implica l'ingegneria sociale o l'accesso fisico.
La mia raccomandazione, tuttavia, è che non si memorizzano mai password in chiaro ovunque. Se hai bisogno di un promemoria, ti suggerisco di utilizzare un prompt incompleto parziale che guidi la tua memoria e ti permetta di dedurre le password, ma ragionevolmente impedisce ad altre persone di farlo, anche se ti conoscono. Questo è molto lontano dall'ideale, ma meglio delle password in chiaro.