Regardless; Could a malicious program theoretically steal data from primary memory (RAM)?
Con permessi sufficienti, assolutamente. Il modo in cui i computer moderni gestiscono la memoria è un po 'complesso, ma il succo è facile da capire. Un computer x86 utilizza due "squilli" di privilegi, chiamati ring 0 e ring 3 (ne ha di più, ma non sono utilizzati da nessun sistema operativo popolare). Ring 0 è altamente privilegiato e può fare praticamente qualsiasi cosa. L'anello 3 è meno privilegiato e deve chiedere al codice che gira nell'anello 0 (il kernel) di fare qualcosa di privilegiato a suo nome (si tratta di una chiamata di sistema). Su tutti i moderni processori x86, esiste una protezione aggiuntiva, denominata Memory Management Unit o MMU. Permette ad ogni processo di avere il proprio spazio di indirizzamento virtuale, e se tenta di accedere a qualsiasi altra memoria, si blocca.
Quindi sembra che tutti i processi siano isolati, giusto? Sfortunatamente non è così semplice. Il kernel, che gira nell'anello 0, fornisce un'interfaccia per i processi per comunicare tra loro e persino per accedere alla memoria l'uno dell'altro indirettamente, utilizzando una chiamata di sistema. Indipendentemente dal fatto che la chiamata di sistema sia consentita dipende dalle autorizzazioni del processo. Un processo dannoso con autorizzazioni elevate può semplicemente chiedere al kernel di dargli accesso alla memoria di un altro processo, e il kernel sarà felice di farlo. Processi dannosi senza permessi non sono in grado di farlo. È importante notare, tuttavia, che su molti sistemi, semplicemente l'esecuzione come lo stesso utente di un altro processo è considerata un permesso sufficiente. Due processi in esecuzione come lo stesso utente possono quindi leggere e scrivere l'uno nella memoria dell'altro su alcuni sistemi.
La prima risposta spiegava come funziona su Windows. Su Linux, i modi equivalenti per leggere le memorie di un altro processo sono le chiamate di sistema ptrace() , process_vm_readv() e il /proc/<pid>/mem file. I primi due controllano che il processo chiamante sia eseguito come lo stesso utente della destinazione, o che abbia permessi di override specifici (eccetto su alcuni sistemi con funzionalità di sicurezza aggiuntive). Il secondo file può essere letto solo dal programma che lo possiede.
Although the passwords.txt file is only 'stored' in permanent secondary memory on the USB, it will briefly appear within the RAM of the computer which I use to mount the USB, decrypt the data, and open the file. It is here that I suspect a weakness my reside.
In realtà la chiave è costantemente in memoria, non solo brevemente. Rimarrà in memoria fino a quando il dispositivo è montato. Questo è fondamentalmente necessario per la crittografia / decrittografia al lavoro. Si noti che probabilmente sarà una derivata della password, non della password stessa, ma è comunque sufficiente per decodificare l'unità. Tuttavia è presente nel kernel che, essendo ring 0, non può essere utilizzato dai normali processi.
(Side question): Aside from the obvious Anti-Virus solution to mitigate a malicious program, how may RAM be protected?
Supponendo che non ci siano bug sfruttabili, due processi vengono eseguiti in quanto utenti diversi non saranno in grado di accedere alla memoria l'uno dell'altro. Esecuzione di un utente come un altro processo fornisce un migliore isolamento. Si noti che, su Windows e sulla maggior parte di Linux, se due processi grafici di utenti diversi vengono eseguiti contemporaneamente, possono comunque comunicare tramite API grafiche. Windows tenta di bloccarlo, ma è stato ripetutamente ignorato. Inoltre, se il kernel è compromesso (che richiede uno sfruttamento avanzato), tutte le scommesse sono disattivate, in quanto il codice ring 0 può accedere a qualsiasi memoria in circostanze normali.
L'antivirus non aiuta molto, dal momento che tende a proteggere solo da malware vecchi, scritti male o già scoperti e prodotti in serie. Il malware specializzato, anche se abbastanza dilettante, continuerà a bypassare l'antivirus con un'alta probabilità.