Virus in GNU / Linux: realtà o mito?

Ogni volta che il dibattito è finito virus y GNU / Linux non ci vuole molto prima che l'utente appaia (solitamente Windows) cosa dice:

«In Linux non ci sono virus perché i creatori di questi programmi dannosi non perdono tempo a fare qualcosa per un sistema operativo che quasi nessuno usa »

A cui ho sempre risposto:

"Il problema non è quello, ma i creatori di questi programmi dannosi non perderanno tempo a creare qualcosa che verrà corretto con il primo aggiornamento del sistema, anche in meno di 24 ore"

E non mi sbagliavo, visto che questo ottimo articolo pubblicato nel Numero 90 (Anno 2008) da Todo Linux Magazine. Il suo attore david santo orcero ci fornisce in modo tecnico (ma facile da capire) la spiegazione perché GNU / Linux manca questo tipo di software dannoso.

Consigliato al 100%. Ora avranno materiale più che convincente per mettere a tacere chiunque parli senza una base solida su questo argomento.

Scarica l'articolo (PDF): Miti e fatti: Linux e virus

MODIFICATO:

Ecco l'articolo trascritto, poiché riteniamo che sia molto più comodo da leggere in questo modo:

================================================== ======================

Il dibattito su Linux e sui virus non è una novità. Ogni tanto vediamo una mail in una lista che chiede se ci sono virus per Linux; e automaticamente qualcuno risponde affermativamente e afferma che se non sono più popolari è perché Linux non è così diffuso come Windows. Ci sono anche frequenti comunicati stampa di sviluppatori di antivirus che affermano di rilasciare versioni di virus Linux.

Personalmente ho avuto qualche altra discussione con persone diverse per posta, o per lista di distribuzione, riguardo alla questione se i virus esistessero o meno in Linux. È un mito, ma è difficile demolire un mito o, meglio, una bufala, soprattutto se è causato da interessi economici. Qualcuno è interessato a trasmettere l'idea che se Linux non ha questo tipo di problemi, è perché pochissime persone lo usano.

Al momento della pubblicazione di questo rapporto, avrei voluto scrivere un testo definitivo sull'esistenza dei virus in Linux. Sfortunatamente, quando la superstizione e l'interesse economico dilagano, è difficile costruire qualcosa di definitivo.
Tuttavia, proveremo qui a fare un argomento ragionevolmente completo per disarmare gli attacchi di chiunque voglia discutere.

Cos'è un virus?

Prima di tutto, inizieremo definendo cosa sia un virus. È un programma che copia se stesso e viene eseguito automaticamente e che mira ad alterare il normale funzionamento di un computer, senza il permesso o la conoscenza dell'utente. Per fare ciò, i virus sostituiscono i file eseguibili con altri infettati dal loro codice. La definizione è standard ed è un riepilogo di una riga della voce di Wikipedia sui virus.
La parte più importante di questa definizione, e quella che differenzia il virus da altri malware, è che un virus si installa da solo, senza il permesso o la conoscenza dell'utente. se non si installa da solo, non è un virus: potrebbe essere un rootkit o un Trojan.

Un rootkit è una patch del kernel che consente di nascondere determinati processi alle utilità dell'area utente. In altre parole, è una modifica del codice sorgente del kernel il cui scopo è che le utilità che ci consentono di vedere cosa è in esecuzione in un dato momento non visualizzano un determinato processo o un determinato utente.

Un Trojan è analogo: è una modifica al codice sorgente di un servizio specifico per nascondere determinate attività fraudolente. In entrambi i casi, è necessario ottenere il codice sorgente della versione esatta installata sulla macchina Linux, patchare il codice, ricompilarlo, ottenere privilegi di amministratore, installare l'eseguibile patchato e inizializzare il servizio - nel caso del Trojan– o il sistema operativo completo - nel caso di
rootkit–. Il processo, come si vede, non è banale e nessuno può fare tutto questo "per sbaglio". Entrambi richiedono nella loro installazione che qualcuno con privilegi di amministratore, consapevolmente, esegua una serie di passaggi che prendono decisioni di natura tecnica.

Che non è una sfumatura semantica poco importante: perché un virus si installi da solo, tutto ciò che dobbiamo fare è eseguire un programma infetto come un utente comune. D'altra parte, per l'installazione di un rootkit o di un Trojan è essenziale che un malintenzionato entri personalmente nell'account root di una macchina e, in modo non automatizzato, esegua una serie di passaggi potenzialmente rilevabili. un virus si diffonde rapidamente ed efficacemente; un rootkit o un trojan ha bisogno di loro per mirare specificamente a noi.

Trasmissione di virus in Linux:

Il meccanismo di trasmissione di un virus, quindi, è ciò che realmente lo definisce come tale, ed è alla base della loro esistenza. Un sistema operativo è più sensibile ai virus quanto più è facile sviluppare un meccanismo di trasmissione efficiente e automatizzato.

Supponiamo di avere un virus che vuole diffondersi. Supponiamo che sia stato lanciato da un utente normale, innocentemente, all'avvio di un programma. Questo virus ha esclusivamente due meccanismi di trasmissione:

• Replicarsi toccando la memoria di altri processi, ancorandosi ad essi in fase di runtime.
• Apertura degli eseguibili del filesystem e aggiunta del loro codice –payload– all'eseguibile.

Tutti i virus che possiamo considerare come tali hanno almeno uno di questi due meccanismi di trasmissione. O I due. Non ci sono più meccanismi.
Per quanto riguarda il primo meccanismo, ricordiamo l'architettura della memoria virtuale di Linux e come funzionano i processori Intel. Questi hanno quattro anelli, numerati da 0 a 3; minore è il numero, maggiori sono i privilegi che ha il codice che gira in quell'anello. Questi anelli corrispondono agli stati del processore e, quindi, a ciò che può essere fatto con un sistema che si trova in un anello specifico. Linux fa uso dell'anello 0 per il kernel e dell'anello 3 per i processi. non c'è codice di processo che gira sull'anello 0 e non c'è codice del kernel che gira sull'anello 3. C'è solo un singolo punto di ingresso al kernel dall'anello 3: l'interrupt 80h, che permette di saltare dall'area in cui si trova il codice utente nell'area in cui si trova il codice del kernel.

L'architettura di Unix in generale e di Linux in particolare non rende possibile la diffusione dei virus.

Il kernel utilizzando la memoria virtuale fa credere a ogni processo di avere tutta la memoria per sé. Un processo - che funziona nell'anello 3 - può vedere solo la memoria virtuale che è stata configurata per esso, per l'anello in cui opera. Non è che la memoria degli altri processi sia protetta; è che per un processo la memoria degli altri è al di fuori dello spazio degli indirizzi. Se un processo dovesse battere tutti gli indirizzi di memoria, non sarebbe nemmeno in grado di fare riferimento a un indirizzo di memoria di un altro processo.

Perché questo non può essere ingannato?
Modificare quanto commentato - ad esempio, generare punti di ingresso nell'anello 0, modificare vettori di interrupt, modificare la memoria virtuale, modificare LGDT… - è possibile solo dall'anello 0.
Cioè, affinché un processo sia in grado di toccare la memoria di altri processi o il kernel, dovrebbe essere il kernel stesso. E il fatto che ci sia un unico punto di ingresso e che i parametri vengano passati attraverso i registri complica la trappola - infatti, viene passato attraverso il registro fino a cosa fare, che viene poi implementato come un caso nella routine di attenzione. 80 ore di interruzione.
Un altro scenario è il caso dei sistemi operativi con centinaia di chiamate non documentate allo squillo 0, dove ciò è possibile - può sempre esserci una chiamata dimenticata mal implementata su cui è possibile sviluppare una trappola - ma nel caso di un sistema operativo con tale semplice meccanismo a gradini, non lo è.

Per questo motivo, l'architettura della memoria virtuale impedisce questo meccanismo di trasmissione; nessun processo, nemmeno quelli con privilegi di root, ha un modo per accedere alla memoria degli altri. Potremmo sostenere che un processo può vedere il kernel; Lo ha mappato dal suo indirizzo di memoria logica 0xC0000000. Ma, a causa dell'anello del processore su cui gira, non puoi modificarlo; genererebbe una trappola, poiché sono aree di memoria che appartengono ad un altro anello.

La "soluzione" sarebbe un programma che modifica il codice del kernel quando è un file. Ma il fatto che questi vengano ricompilati lo rende impossibile. Non è possibile patchare il binario, poiché ci sono milioni di diversi kernel binari nel mondo. Semplicemente che durante la ricompilazione avevano messo o rimosso qualcosa dall'eseguibile del kernel, oppure avevano cambiato la dimensione di una delle etichette che identificano la versione della compilazione - cosa che viene fatta anche involontariamente - la patch binaria non poteva essere applicata. L'alternativa sarebbe scaricare il codice sorgente da Internet, correggerlo, configurarlo per l'hardware appropriato, compilarlo, installarlo e riavviare la macchina. Tutto questo dovrebbe essere fatto da un programma, automaticamente. Una bella sfida per il campo dell'intelligenza artificiale.
Come possiamo vedere, nemmeno un virus come root può superare questa barriera. L'unica soluzione rimasta è la trasmissione tra file eseguibili. Che non funziona neanche come vedremo di seguito.

La mia esperienza come amministratore:

In più di dieci anni ho gestito Linux, con installazioni su centinaia di macchine in data center, laboratori studenteschi, aziende, ecc.

• Non ho mai "preso" un virus
• Non ho mai incontrato qualcuno che lo abbia fatto
• Non ho mai incontrato qualcuno che abbia incontrato qualcuno che l'ha fatto

Conosco più persone che hanno visto il mostro di Loch Ness di quante ne abbiano visti i virus per Linux.
Personalmente ammetto di essere stato spericolato, e ho lanciato diversi programmi che gli autoproclamati "specialisti" chiamano "virus per Linux" - d'ora in poi li chiamerò virus, per non rendere pedante il testo -, da il mio solito account contro la mia macchina per vedere se un virus è possibile: sia il virus bash che circola lì intorno - e che, tra l'altro, non ha infettato alcun file - sia un virus che è diventato molto famoso ed è apparso sulla stampa. Ho provato a installarlo; e dopo venti minuti di lavoro, ho rinunciato quando ho visto che una delle sue richieste era quella di avere la directory tmp su una partizione di tipo MSDOS. Personalmente, non conosco nessuno che crei una partizione specifica per tmp e la formatta in FAT.
In effetti, alcuni cosiddetti virus che ho testato per Linux richiedono un alto livello di conoscenza e la password di root per essere installati. Potremmo qualificarci, come minimo, come un virus "schifoso" se ha bisogno del nostro intervento attivo per infettare la macchina. Inoltre, in alcuni casi richiedono una conoscenza approfondita di UNIX e della password di root; che è abbastanza lontano dall'installazione automatica che dovrebbe essere.

Infezione di eseguibili su Linux:

Su Linux, un processo può semplicemente fare ciò che il suo utente effettivo e il suo gruppo effettivo consentono. È vero che esistono meccanismi per scambiare l'utente reale con denaro contante, ma poco altro. Se guardiamo dove sono gli eseguibili, vedremo che solo root ha i privilegi di scrittura sia in queste directory che nei file contenuti. In altre parole, solo root può modificare tali file. Questo è il caso di Unix dagli anni '70, di Linux sin dalle sue origini, e in un file system che supporta i privilegi, non è ancora apparso alcun errore che consenta altri comportamenti. La struttura dei file eseguibili ELF è nota e ben documentata, quindi è tecnicamente possibile per un file di questo tipo caricare il payload in un altro file ELF ... purché l'utente effettivo del primo o del gruppo effettivo del primo ha i privilegi di accesso, lettura, scrittura ed esecuzione sul secondo file. Quanti eseguibili del filesystem potrebbe infettare come un utente comune?
Questa domanda ha una risposta semplice, se vogliamo sapere quanti file potremmo "infettare", lanciamo il comando:

$ find / -type f -perm -o=rwx -o \( -perm -g=rwx -group `id -g` \) -o \( -perm -u=rwx -user `id -u` \) -print 2> /dev/null | grep -v /proc

Escludiamo la directory / proc perché è un filesystem virtuale che mostra le informazioni su come funziona il sistema operativo. I file di tipo file con privilegi di esecuzione che troveremo non rappresentano un problema, poiché spesso sono collegamenti virtuali che sembrano essere letti, scritti ed eseguiti, e se un utente lo prova, non funziona mai. Si escludono anche errori, numerosi - poiché, soprattutto in / proc e / home, ci sono molte directory in cui un utente comune non può entrare - Questo script richiede molto tempo. Nel nostro caso particolare, in una macchina dove lavorano quattro persone, la risposta è stata:

/tmp/.ICE-unix/dcop52651205225188
/tmp/.ICE-unix/5279
/home/irbis/kradview-1.2/src
/kradview

L'output mostra tre file che potrebbero essere infettati se fosse eseguito un ipotetico virus. I primi due sono file di tipo socket Unix che vengono eliminati all'avvio - e non possono essere influenzati da un virus -, e il terzo è un file di un programma in sviluppo, che viene eliminato ogni volta che viene ricompilato. Il virus, da un punto di vista pratico, non si diffonderebbe.
Da quello che vediamo, l'unico modo per diffondere il carico utile è essere root. In questo caso, affinché un virus funzioni, gli utenti devono sempre disporre dei privilegi di amministratore. In tal caso può infettare i file. Ma ecco il trucco: per trasmettere l'infezione, è necessario prendere un altro eseguibile, inviarlo per posta a un altro utente che utilizza la macchina solo come root e ripetere il processo.
Nei sistemi operativi in ​​cui è necessario essere un amministratore per attività comuni o per eseguire molte applicazioni quotidiane, questo può essere il caso. Ma in Unix è necessario essere un amministratore per configurare la macchina e modificare i file di configurazione, quindi il numero di utenti che l'account root utilizza come account giornaliero è piccolo. È più; alcune distribuzioni Linux non hanno nemmeno l'account root abilitato. In quasi tutti, se accedi all'ambiente grafico in quanto tale, lo sfondo diventa rosso intenso e vengono ripetuti messaggi costanti che ti ricordano di non usare questo account.
Infine, tutto ciò che deve essere fatto come root può essere fatto con un comando sudo senza rischi.
Per questo motivo, in Linux un eseguibile non può infettare altri finché non si utilizza l'account di root come account di uso comune; E sebbene le aziende antivirus insistano nel dire che esistono virus per Linux, la cosa più simile che può essere creata in Linux è un Trojan nell'area dell'utente. L'unico modo in cui questi Trojan possono influenzare qualcosa sul sistema è eseguirlo come root e con i privilegi necessari. Se usiamo abitualmente la macchina come utenti ordinari, non è possibile che un processo avviato da un utente comune infetti il ​​sistema.

Miti e bugie:

Troviamo molti miti, bufale e semplici bugie sui virus in Linux. Facciamo un elenco sulla base di una discussione avvenuta qualche tempo fa con un rappresentante di un produttore di antivirus per Linux che è stato molto offeso da un articolo pubblicato su questa stessa rivista.
Questa discussione è un buon esempio di riferimento, poiché tocca tutto ciò che riguarda i virus in Linux. Rivedremo tutti questi miti uno per uno così come sono stati discussi in quella specifica discussione, ma che è stato ripetuto tante volte in altri forum.

Mito 1:
"Non tutti i programmi dannosi, in particolare i virus, necessitano dei privilegi di root per infettare, soprattutto nel caso particolare di virus eseguibili (formato ELF) che infettano altri eseguibili".

Risposta:
Chiunque faccia una simile affermazione non sa come funziona il sistema dei privilegi di Unix. Per influenzare un file, un virus ha bisogno del privilegio di lettura - deve essere letto per modificarlo - e di scrivere - deve essere scritto affinché la modifica sia valida - sul file eseguibile che vuole eseguire.
È sempre così, senza eccezioni. E in ogni distribuzione, gli utenti non root non hanno questi privilegi. Quindi semplicemente non essendo root, l'infezione non è possibile. Test empirico: nella sezione precedente abbiamo visto un semplice script per controllare la gamma di file che possono essere colpiti da un'infezione. Se lo lanciamo sulla nostra macchina, vedremo come è trascurabile e, rispetto ai file di sistema, nullo. Inoltre, a differenza dei sistemi operativi come Windows, non sono necessari privilegi di amministratore per eseguire attività comuni con i programmi comunemente utilizzati dagli utenti normali.

Mito 2:
"Né è necessario essere root per entrare nel sistema da remoto, nel caso di Slapper, un worm che, sfruttando una vulnerabilità dell'SSL di Apache (i certificati che consentono la comunicazione sicura), ha creato una propria rete di macchine zombie nel settembre 2002".

Risposta:
Questo esempio non si riferisce a un virus, ma a un worm. La differenza è molto importante: un worm è un programma che sfrutta un servizio affinché Internet si trasmetta. Non influisce sui programmi locali. Pertanto, interessa solo i server; non a macchine particolari.
I vermi sono sempre stati pochissimi e di incidenza trascurabile. I tre veramente importanti sono nati negli anni '80, un tempo in cui Internet era innocente e tutti si fidavano di tutti. Ricordiamo che sono stati quelli che hanno influenzato sendmail, fingerd e rexec. Oggi le cose sono più complicate. Anche se non si può negare che esistano ancora e che, se lasciati incontrollati, sono estremamente pericolosi. Ma ora, i tempi di reazione ai vermi sono molto brevi. Questo è il caso dello Slapper: un worm creato su una vulnerabilità scoperta - e corretta - due mesi prima della comparsa del worm stesso.
Anche supponendo che tutti coloro che usano Linux avessero Apache installato e funzionante tutto il tempo, il semplice aggiornamento mensile dei pacchetti sarebbe stato più che sufficiente per non correre alcun rischio.
È vero che il bug SSL causato da Slapper era critico - in effetti, il bug più grande trovato nell'intera storia di SSL2 e SSL3 - e come tale è stato risolto in poche ore. Che due mesi dopo che questo problema è stato trovato e risolto, qualcuno ha creato un worm su un bug che è già stato corretto, e che questo è l'esempio più potente che può essere dato come vulnerabilità, almeno rassicura.
Come regola generale, la soluzione ai worm non è quella di acquistare un antivirus, installarlo e sprecare tempo di elaborazione per mantenerlo residente. La soluzione è utilizzare il sistema di aggiornamento della sicurezza della nostra distribuzione: con la distribuzione aggiornata non ci saranno problemi. Anche eseguire solo i servizi di cui abbiamo bisogno è una buona idea per due motivi: miglioriamo l'uso delle risorse ed evitiamo problemi di sicurezza.

Mito 3:
"Non credo che il nucleo sia invulnerabile. Esiste infatti un gruppo di programmi dannosi chiamati LRK (Linux Rootkits Kernel), che si basano proprio sullo sfruttamento delle vulnerabilità nei moduli del kernel e sulla sostituzione dei binari di sistema.".

Risposta:
Un rootkit è fondamentalmente una patch del kernel che permette di nascondere l'esistenza di determinati utenti e processi ai soliti strumenti, grazie al fatto che non appariranno nella directory / proc. La cosa normale è che lo usano alla fine di un attacco, in primo luogo, sfrutteranno una vulnerabilità remota per ottenere l'accesso alla nostra macchina. Quindi intraprenderanno una sequenza di attacchi, per aumentare i privilegi fino a quando non avranno l'account di root. Il problema quando lo fanno è come installare un servizio sulla nostra macchina senza essere rilevati: è qui che entra in gioco il rootkit. Viene creato un utente che sarà l'utente effettivo del servizio che vogliamo nascondere, installano il rootkit e nascondono sia quell'utente che tutti i processi che appartengono a quell'utente.
Come nascondere l'esistenza di un utente è utile a un virus è qualcosa di cui potremmo discutere a lungo, ma un virus che utilizza un rootkit per installarsi sembra divertente. Immaginiamo la meccanica del virus (in pseudocodice):
1) Il virus entra nel sistema.
2) Individua il codice sorgente del kernel. Se non lo è, lo installa lui stesso.
3) Configurare il kernel per le opzioni hardware che si applicano alla macchina in questione.
4) Compila il kernel.
5) Installa il nuovo kernel; modificando LILO o GRUB se necessario.
6) Riavvia la macchina.

I passaggi (5) e (6) richiedono i privilegi di root. È piuttosto complicato che i passaggi (4) e (6) non vengano rilevati dagli infetti. Ma la cosa divertente è che c'è qualcuno che crede che esista un programma in grado di eseguire automaticamente i passaggi (2) e (3).
In conclusione, se ci imbattiamo in qualcuno che ci dice "quando ci saranno più macchine Linux ci saranno più virus" e ci consiglia di "avere un antivirus installato e aggiornarlo costantemente", potrebbe essere correlato all'azienda che vende l'antivirus e gli aggiornamenti. Sii sospettoso, forse lo stesso proprietario.

Antivirus per Linux:

È vero che esistono buoni antivirus per Linux. Il problema è che non fanno ciò che sostengono i sostenitori dell'antivirus. La sua funzione è quella di filtrare la posta che passa da malware e virus a Windows, nonché di verificare l'esistenza di virus Windows in cartelle esportate tramite SAMBA; quindi se usiamo la nostra macchina come gateway di posta o come NAS per macchine Windows, possiamo proteggerli.

Vongola-AV:

Non finiremo il nostro reportage senza parlare del principale antivirus per GNU / Linux: ClamAV.
ClamAV è un antivirus GPL molto potente che compila per la maggior parte degli Unix disponibili sul mercato. È progettato per analizzare gli allegati ai messaggi di posta che passano attraverso la stazione e filtrarli alla ricerca di virus.
Questa applicazione si integra perfettamente con sendmail per consentire il filtraggio dei virus che possono essere archiviati nei server Linux che forniscono posta alle aziende; disporre di un database dei virus aggiornato quotidianamente, con supporto digitale. Il database viene aggiornato più volte al giorno, ed è un progetto vivace e molto interessante.
Questo potente programma è in grado di analizzare i virus anche negli allegati in formati più complessi da aprire, come RAR (2.0), Zip, Gzip, Bzip2, Tar, MS OLE2, file MS Cabinet, MS CHM (HTML COprinted) e MS SZDD .
ClamAV supporta anche file di posta mbox, Maildir e RAW e file eseguibili portatili compressi con UPX, FSG e Petite. Clam AV e la coppia spamassassin sono la coppia perfetta per proteggere i nostri client Windows dai server di posta Unix.

CONCLUSIONE

Alla domanda Esistono vulnerabilità nei sistemi Linux? la risposta è sicuramente sì.
Nessuno sano di mente ne dubita; Linux non è OpenBSD. Un'altra cosa è la finestra di vulnerabilità di un sistema Linux che è adeguatamente aggiornata. Se ci chiediamo, esistono strumenti per trarre vantaggio da queste falle di sicurezza e sfruttarle? Ebbene sì, ma questi non sono virus, sono exploit.

Il virus deve superare molte altre difficoltà che sono sempre state indicate come un difetto / problema di Linux dai difensori di Windows e che complicano l'esistenza di virus reali: kernel che vengono ricompilati, molte versioni di molte applicazioni, molte distribuzioni, cose che non sono passato automaticamente in modo trasparente all'utente, ecc. -. Gli attuali "virus" teorici devono essere installati manualmente dall'account root. Ma questo non può essere considerato un virus.
Come dico sempre ai miei studenti: non credetemi, per favore. Scarica e installa un rootkit sulla macchina. E se vuoi di più, leggi il codice sorgente dei "virus" in commercio. La verità è nel codice sorgente. È difficile per un virus "autoproclamato" continuare a chiamarlo in questo modo dopo aver letto il suo codice. E se non sai come leggere il codice, un'unica semplice misura di sicurezza che ti consiglio: usa l'account root solo per amministrare la macchina e mantieni aggiornati gli aggiornamenti di sicurezza.
Solo con questo è impossibile che i virus entrino in te ed è molto improbabile che i worm o qualcuno attacchino la tua macchina con successo.