[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]
Nello studio dei problemi di sicurezza legati all'uso di strumenti informatici, non vanno trascurati i virus e il software modificato ad arte per arrecare qualche tipo di danno. Lo scopo di questo capitolo è quello di fare comprendere il problema, pur senza poterlo risolvere in modo definitivo.
Di per sé, non è molto importante classificare il software che arreca danno in qualche modo, se non per il fatto che questo permette di avere una visione un po' più chiara del problema. In generale si distinguono due tipi fondamentali: i virus e i cavalli di Troia. Eventualmente si considerano anche i vermi, come sottogruppo particolare dei virus.
Il virus è un pezzo di codice in grado di riprodursi nel sistema, attaccandosi ai programmi già esistenti, agli script, sostituendosi al settore di avvio di un disco o di una partizione, inserendosi all'interno di file di dati che prevedono la presenza di macroistruzioni. Naturalmente, un virus non è necessariamente in grado di fare tutto questo simultaneamente: dipende da chi lo realizza il modo in cui riuscirà a riprodursi.
Un cavallo di Troia, o trojan (troiano), è un programma che di per sé svolgerebbe una funzione più o meno utile, che però nasconde una parte di codice indesiderabile. Il classico cavallo di Troia è un gioco, che mentre viene utilizzato fa anche qualcosa di diverso, come cancellare dei file, oppure spedire all'esterno informazioni sulla configurazione del proprio sistema. Un cavallo di Troia potrebbe essere anche un programma normale che sia stato infettato ad arte con un virus, allo scopo di diffondere il virus stesso.
Il verme è un sottoinsieme specifico dei virus, il cui intento principale è quello di diffondersi attraverso la rete. Generalmente, anche se non sempre, il verme si cancella una volta che è riuscito a copiarsi all'esterno.
Si comprende facilmente il senso di un cavallo di Troia. Come sempre vale la solita raccomandazione: «non accettare nulla -- caramelle o qualunque altra cosa -- dagli estranei». Infatti, una caramella può essere avvelenata, un oggetto appuntito potrebbe essere stato infettato con qualche sostanza,(1) così come un programma può essere stato alterato ad arte. Purtroppo, spesso non ci sono alternative alla «fiducia», soprattutto quando il programma in questione è accessibile solo in forma di eseguibile senza sorgente.
Ad aggravare il problema, le normative di vari paesi vietano espressamente la decompilazione, cioè lo studio dei programmi a partire dalla loro forma eseguibile, cosa che rende difficile una verifica a seguito dell'insorgere di un qualche sospetto. L'unica possibilità per salvaguardarsi di fronte a questo problema è l'uso di programmi provvisti di sorgente, verificati e compilati personalmente.(2) Evidentemente non si tratta di una soluzione accessibile a tutti, sia per le capacità necessarie, sia per il tempo che ciò richiede. Purtroppo, però, resta l'unica, se si vuole escludere la fiducia.
La fiducia, ammesso che ci sia, non basta, perché occorre verificare che il tale programma non sia stato manomesso da una persona differente da quella di cui ci si fida. Infatti, un programma normale potrebbe diventare un cavallo di Troia contenente un virus, o comunque contenere qualcosa di aggiunto per qualche fine. Questa verifica può essere fatta attraverso l'uso di una firma elettronica (si veda a questo proposito il capitolo 195).
Una volta compreso il pericolo legato ai programmi, che possono essere cavalli di Troia, oppure possono contenere un virus, si può credere di avere risolto il problema se si evita di installarne di nuovi. Tuttavia, un «programma» può essere inserito anche all'interno di file di dati, nel momento in cui questo può diventare uno script o un insieme di macro-istruzioni di qualche tipo.
È nota l'esistenza di virus «macro», costituiti da macro-istruzioni contenute in documenti di programmi di scrittura o in fogli elettronici. Nello stesso modo non è da escludere la possibilità di acquisire un documento TeX o anche PostScript contenente istruzioni che possono arrecare dei danni nel momento della composizione (si tratta di operazioni legate all'accesso al file system).
Sotto questo aspetto, i problemi maggiori si avvertono quando i programmi di questo tipo possono essere inseriti in documenti a cui si accede attraverso la rete. Per esempio, una pagina HTML potrebbe incorporare uno script Java,(3) o peggio un programma Java (le applet). In questa situazione, solo il programma di navigazione può impedire che venga fatto qualcosa di dannoso, ammesso che possa essere in grado di farlo. Generalmente, l'unica alternativa è impedire l'esecuzione di script e programmi esterni, accettando tutte le conseguenze che ciò comporta, dato che in questo modo diventa impossibile accedere ad alcuni servizi.
Un'ultima considerazione va fatta nei confronti dei programmi allegati a messaggi di posta elettronica. Nel momento in cui il programma di lettura della posta dovesse essere «troppo» amichevole, si potrebbe arrivare a estrarre e installare tali programmi, quasi senza rendersene conto. Sono noti gli attacchi di questo tipo che colpiscono inesorabilmente gli utenti più ingenui.
In linea di principio, non ci sono difese che tengano contro un virus o un cavallo di Troia realizzati con perizia. Tuttavia, qualche accorgimento può essere utile, soprattutto se si ritiene che il proprio sistema operativo di partenza sia abbastanza «sicuro» (cosa che comunque non si può dimostrare). In generale valgono le solite raccomandazioni che si fanno in queste occasioni.
Evitare di utilizzare software che non sia stato compilato personalmente, dopo un esame attento dei sorgenti, o comunque, evitare di utilizzare software compilato da persone sconosciute e anche da persone conosciute per le quali non si può verificare l'autenticità dell'origine.
Evitare di abilitare l'esecuzione di script e programmi incorporati in documenti ottenuti attraverso la rete (file HTML e posta elettronica principalmente).
Evitare di usare il sistema in qualità di utente root quando non serve: un virus avrebbe i privilegi necessari per infettare tutto il sistema, mentre un cavallo di Troia avrebbe accesso a tutti i file di dispositivo.
Utilizzare un sistema di scansione realizzato appositamente per verificare le alterazioni nei file, come AIDE e Tripwire (capitolo 188).
Un sistema Unix è l'ideale per realizzare un virus con grande facilità. Non serve nemmeno essere programmatori; basterebbe appena sapere scrivere uno script di shell.
Qui non si vuole e non si può mostrare un esempio pratico di virus del genere, perché la diffusione di tali informazioni potrebbe invogliare le solite persone di poco conto a realizzarne dei propri. Tuttavia, la descrizione di massima del funzionamento di un virus reale può essere di aiuto per comprendere il problema.
Bliss è stato il primo virus realizzato specificatamente per i sistemi GNU/Linux, che comunque potrebbe essere ricompilato facilmente per la maggior parte dei sistemi Unix. Le informazioni sul suo funzionamento sono state ottenute da un'analisi condotta da Ray Lehtiniemi, come documentato in Bliss, a Linux "virus" di Axel Boldt.
Bliss si attacca ai file eseguibili (compresi gli script) nella loro parte iniziale, aggiungendo in coda una stringa di riconoscimento (una firma, ovvero un'impronta virale). Quando si avvia un programma infettato in questo modo, in realtà si mette in funzione il virus, che fa le sue cose e poi estrae il file originale salvandolo temporaneamente in /tmp/.bliss-tmp.pid (pid rappresenta il numero del processo), da dove poi provvede a metterlo in funzione.
|
È da osservare che tutto è molto semplice, al contrario di tanti virus realizzati per sistemi Dos e successivi, in cui si arriva ad alterare le istruzioni del codice eseguibile che viene infettato. |
Bliss è evidentemente solo una dimostrazione di questo pericolo. Qui sono stati trascurati tanti dettagli sul suo funzionamento che riguardano però lo scopo «pratico». Ma per comprendere cosa può fare un virus, basta solo un po' di fantasia. Si intuisce facilmente il pericolo di un virus latente, che non fa nulla di eclatante per mostrarsi, rimanendo in attesa di fare ciò per cui è stato creato e messo in circolazione.
Axel Boldt, Bliss, a Linux "virus"
daniele @ swlibero.org1) Secondo una vecchia tradizione non si regalano spille e altri oggetti appuntiti con cui ci si può ferire.
2) Esiste anche software proprietario che viene messo a disposizione in forma sorgente.
3) Teoricamente i file HTML possono incorporare anche molti altri tipi di script, purché il navigatore sia poi in grado di interpretarli.
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome virus_vermi_e_cavalli_di_troia.html
[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]