Qualcuno qui al lavoro ha appena fatto una richiesta interessante; hanno affermato che è possibile che il malware venga avviato, ad es. Windows, per rimanere nella RAM tramite un riavvio e continuare a lavorare in Linux sulla macchina all'avvio.
Hanno ragione? Sono quasi sicuro che sia impossibile, ma sono felice di essere corretto.
Non sono corretti . Tutto ciò che rimane in memoria dopo il riavvio della macchina, anche se non sovrascritto, non sarà attivo. Questo perché non c'è alcun codice in nessun sistema operativo usato che guarda nello spazio non allocato in memoria ed esegue qualsiasi cosa che assomigli al codice. Mentre è possibile che malware appositamente progettato sia multipiattaforma e infetti un altro sistema operativo in virtù dell'accesso al dispositivo di archiviazione su cui risiede, non sarà in grado di persistere un'infezione rimanendo in memoria dopo il riavvio. Per una descrizione più completa del processo di avvio, vedi Inizializzazione del sistema (x86) - OSDev .
Si noti che questo si applica solo alla memoria di sistema. In teoria, malware che gira sulla GPU può persistere durante il riavvio. La ragione di ciò è che un caldo riavvio ripristina solo la CPU. Non alimenta le periferiche del ciclo, quindi una GPU discreta eseguirà ancora il codice e conserverà la memoria durante il processo di avvio. I malware che vengono creati per essere eseguiti sulla GPU possono quindi utilizzare accedere direttamente alla memoria per reinserire il codice dannoso nelle operazioni principali sistema. Tuttavia, questo sarà abbastanza specifico per l'hardware e non funzionerà se il dispositivo viene avviato da uno stato a freddo (vale a dire che la potenza viene effettivamente interrotta, inclusa la GPU).
Sono corretti . È certamente possibile che il malware esegua la migrazione tra sistemi operativi sullo stesso host e in molti stili diversi. Per rispondere meglio, è necessario operare distinzioni tra i sistemi operativi virtuali e il dual boot, ma alla fine della giornata, un sistema operativo compromesso può raggiungere e interfacciarsi direttamente con l'host e potenzialmente comprometterlo.
Se stiamo parlando specificamente di uno scenario a doppio avvio: il firmware dannoso potrebbe certamente compromettere ogni sistema operativo sull'host. Quindi, abbiamo accesso fisico per avviarlo da un firmware arbitrario? Il sistema operativo separato in questione è su un HDD separato? Che ne dici di opzioni di avvio sicure, password di amministratore del BIOS, crittografia, ecc.? Abbiamo bisogno di sapere molto di più per dirti in che modo specifico è fatto, sto cercando di dare un contorno generale però.
Se stiamo parlando di uno scenario virtuale: ci sono una tonnellata di diversi tipi di attacchi che circondano le fughe di sandbox dell'hypervisor, tocca a te quello che fai da lì. Un altro utente ha affermato erroneamente che qualunque attacco non sarà probabilmente persistente , e questo è assolutamente sbagliato. Non abbiamo idea di quale fosse il compromesso iniziale. Se sei sfuggito a una sandbox hypervisor o hai avviato l'host da un firmware arbitrario ... È game over in termini di persistenza e diffusione all'intero HDD (a seconda delle condizioni menzionate in precedenza).
Sono richieste informazioni più specifiche per rispondere con precisione a questo in dettaglio. Abbiamo accesso fisico all'host? I sistemi operativi sono virtualizzati? Eccetto il TL; DR è che sì, in teoria il malware può certamente diffondersi tra i sistemi operativi sullo stesso host, sia nello scenario virtuale che dual-boot. Implementazioni completamente diverse vengono applicate tra ciascuna, ma lo stesso obiettivo viene raggiunto ed è estremamente comune nel campo della ricerca sui malware.
Ecco una domanda molto approssimativa che descrive i rischi per la sicurezza tra l'utilizzo della virtualizzazione o il dual boot: C'è un vantaggio in termini di sicurezza nell'utilizzo di una macchina virtuale sul doppio avvio?