È possibile che un virus di qualsiasi tipo sia installato all'interno della partizione di swap di Linux? In tal caso, potrebbe essere trasferito al sistema anche dopo aver formattato solo la partizione Linux e reinstallato il sistema operativo (senza formattare l'area di swap)?
È possibile ma richiede una rotatoria e occorrerebbero rare circostanze per renderlo utile.
Quando avvia Linux, tratta l'area di swap come spazio non allocato. Non rileggerà ciò che era già lì, solo ciò che ha scritto. Quindi, mentre puoi inserire software dannoso, non verrà mai caricato in memoria, per non parlare di essere eseguito.
L'unica eccezione è il ripristino dalla modalità di sospensione. Quando il kernel di Linux si avvia, si può dire che considera una partizione di swap come una potenziale immagine di ibernazione. Se la partizione di swap ha una firma valida (non crittografica), Linux carica i dati dalla partizione di swap in memoria, inclusi i dati del kernel e il codice. Ciò potrebbe includere malware o in generale una backdoor (ad esempio un'immagine di processo di una shell in esecuzione come root e in ascolto su una porta di rete).
Come altri hanno già osservato, la domanda in questo caso è la seguente: se l'autore dell'attacco può scrivere sull'immagine di ibernazione, cosa impedisce loro di scrivere nella partizione di root o nella partizione di avvio? Nella maggior parte delle configurazioni, si trovano sullo stesso dispositivo fisico e possono essere accessibili direttamente solo da qualcuno che ha già il controllo completo (root) sul sistema in primo luogo.
Nello scenario di reinstallazione, in cui un sistema compromesso è stato cancellato dalla reinstallazione, lo scambio è un vettore potenziale di reinfezione. Tuttavia, tutti gli installer che ricordo di aver visto riformattare l'area di swap durante l'installazione, quindi se si esegue una normale installazione, questa non è una preoccupazione. (Potrebbero esserci altri modi per il persistere del malware, infettando un componente hardware che ha una sua memoria flash, ma questo è un'altra domanda .) D'altra parte, se si ripristina la partizione di sistema da una partizione intera backup, quindi il malware potrebbe rimanere indietro. Se si dispone di una procedura di ripristino del sistema, assicurarsi che oltre al ripristino dei file e dei dati di sistema, include i passaggi per reinstallare il bootloader e riformattare lo scambio (cioè eseguire mkswap ).
Un altro scenario in cui lo swap potrebbe essere un vettore di infezione è un attacco di cameriera malvagio . Una protezione contro questo attacco è firmare il bootloader e il sistema (kernel e tutti i file di sistema rilevanti per la sicurezza), con una catena di verifica all'avvio a partire dall'hardware (ad esempio su un PC, con un TPM ). Ma se il kernel e il bootloader sono configurati per supportare l'ibernazione e l'immagine di scambio non è firmata, lo swap diventa un possibile vettore di attacco. (Si noti che la proprietà rilevante è che è firmata , non crittografata , sebbene anche la crittografia non autenticata possa rendere difficile per l'hacker iniettare malware che faccia qualcosa di utile.) essere un errore di configurazione Se si desidera l'integrità del sistema, è necessario assicurarsi di aver protetto tutti i componenti sensibili alla sicurezza.
È difficile pensare a un modo di scrivere nella partizione di swap dato che Linux non ti permette di scrivere su di loro. L'unico scenario che riesco a trovare dove ciò potrebbe essere possibile è quando il sistema sta uscendo dallo stato di sospensione o ibernazione e la memoria è stata sfogliata nel file di scambio. Prima di riavviare Linux, il bootloader o qualche altro codice di avvio fa modifiche dannose alla parte di swap.
Certamente la crittografia della partizione di swap, come suggerito in un commento di @ott, renderebbe la cosa più difficile. Potrebbe non essere impossibile in quanto il sistema operativo deve essere in grado di decrittografare la partizione di swap, ma sarà probabilmente molto più complesso.
Nonostante ciò, non ho mai sentito di un simile attacco. Sospetto che il motivo sia che, quando sarai in grado di modificare il bootloader, hai praticamente immobilizzato il computer e non hai motivo di fare scherzi con attacchi sottili come questo.