Articoli

Premessa

Pensavo fra me e me ad alcuni commenti, raccolti negli ultimi anni da varie persone, riguardanti la possibilità di avere un fenomeno virus in ambiente GNU/Linux. Faccio qui un elenco delle opinioni che mi sono rimaste impresse:

• 1 - I virus su Linux non ci sono perché Linux non lo usa quasi nessuno (attribuzione ignota e multipla)
• 2 - I virus su Linux non ci sono e non ci saranno, perché nella home degli utenti non ci sono quasi mai files eseguibili (attribuzione eweek o osnews o qualche altro sito tipo quelli... non ricordo)
• 3 - I virus su Linux non ci sono e non ci saranno perché Linux è sofware libero quindi il codice di un virus sarebbe visibile a tutti (ometto volontariamente l'attribuzione, non credo che l'autore si lamenterà)
• 4 - I virus su MacOS X non ci sono perché MacOS X è Linux (ometto anche qui, ma alcuni fra di voi potranno immaginare almeno con un certo margine di errore)
• 5 - (fresca d'un paio di giorni al momento della stesura dell'articolo) I virus su MacOS X potrebbero anche esserci ora che i Mac usano processore Intel. Questo perché i G4 e G5 avevano l'OpenFirmware (equivalente del BIOS) che richiede una password, mentre gli Intel no (anche qui ometto l'attribuzione)
• 6 - I virus su Linux non ci sono perché Linux gira su molte architetture hardware diverse
• 7 - (arrivata via email da un lettore del presente articolo l'8 settembre 2007) Finchè Linux, Gnu/Linux e tutto il mondo open source (e sottolineo 'open') vengono sviluppati dagli utenti stessi, e non da una Multinazionale, che utilità avrebbero a creare dei virus atti a distruggere il loro stesso lavoro?
• 8 - I virus su Linux non ci sono perché Linux non è compatibile

Ce ne sarebbero forse altre, ma queste sono quelle che mi vengono in mente subito senza stare a pensarci troppo, per il fatto che sono le più ricorrenti, quelle che vanno per la maggiore (fortunatamente ad eccezione della 5). Prima di tutto vorrei fugare un dubbio: la numero 8 non è incompleta, ma finisce proprio lì senza specificare con cosa non sarebbe compatibile (anche se è facile immaginarlo). Ora mi piacerebbe smontare le vostre convizioni esponendo qui la mia opinione a riguardo e confutando uno alla volta i punti elencati sopra (per alcuni non c'è da far molta fatica).

Linux non è compatibile

Partiamo dall'ultima, che, per quanto sembri una frase che semanticamente non sta in piedi, è forse il punto di vista più corretto e difficile da confutare. Linux non è compatibile. Nella mente di chi l'ha detta, c'era ovviamente uno standard de facto a cui Linux non si conforma, probabilmente qualcosa che ha a che fare con la ridente cittadina di Redmond. Dal punto di vista dei virus, questa affermazione è corretta: un virus fatto per Windows non può funzionare su Linux; se poi c'è di mezzo Wine ha ancora meno probabilità di funzionare, perché piuttosto che avere informazioni sbagliate (caro virus vai tranquillo ché questo è Windows - quando invece è Wine) è meglio non averne affatto (caro virus devi farti furbo perché questo sistema non lo conosci).

Al di là però della compatibilità con Windows, c'è da dire che, sempre dal punto di vista di un virus, Linux non è compatibile nemmeno con sè stesso. Io per esempio sto scrivendo questo articolo usando una Debian Etch ancora in testing che non aggiorno da un mese circa; ciò significa che le versioni di software presenti sul mio sistema sono presenti su un ristretto numero di altri sistemi GNU/Linux (ristretto in percentuale e considerando che un virus può aver bisogno di combinazioni di software in versioni specifiche per poter infettare un sistema). Versioni diverse implicano problemi di sicurezza diversi, mentre un virus, per potersi diffondere, deve poter fare affidamento su problemi di sicurezza comuni a tutti i sistemi che deve attaccare. Oltre a questo, e forse più importante, c'è il fattore dei software alternativi: su GNU/Linux per ogni cosa da fare ci sono vari software alternativi, quindi se un virus sfrutta una falla di firefox per penetrare un sistema, poi potrebbe essere bloccato da konqueror al sistema successivo.

Detta così, la numero 8 sembra un'affermazione davvero difficile da confutare. Analizziamo però la situazione con dati alla mano. do_brk(). Vi ricorda qualcosa? Nel caso in cui non lo sappiate, do_brk() è una funzione presente nel kernel di Linux che ha sofferto in passato di un problema di sicurezza che non sto qui a descrivere, in quanto va oltre lo scopo di questa digressione. Tralasciamo pure il fatto che alcuni server Debian furono violati proprio grazie alla do_brk(), perché in quel caso non si trattava di un virus. Quello su cui vorrei attirare l'attenzione è il fatto che il problema di sicurezza della do_brk() è stato presente nel kernel di Linux a partire dalla prima release del ramo 2.4 fino alla release 2.4.22 inclusa, il che significa in tutti i kernel stabili rilasciati dal gennaio 2001 all'agosto 2003. Due anni e mezzo. Ora possiamo ben dire che i virus hanno vita difficile su Linux perché su una distro ci trovano un kernel 2.4.7 e sull'altra un 2.4.18, ma la realtà è che i problemi di sicurezza, fino a quando non si scoprono, spesso sono presenti ed identici per un numero impressionante di versioni e di mesi. E ovviamente il kernel è solo un esempio, ma il concetto si applica a 360 gradi.

Andiamo oltre, se le versioni diverse non ci mettono al riparo, allora lo faranno i sofware diversi, grazie alle molte alternative che abbiamo in GNU/Linux per ogni tipo di problematica. E qui vorrei ricordare la zlib. Talmente diffusa in software diversi ed eterogenei che un problema di sicurezza nella citata libreria ha coinvolto in un colpo solo la maggior parte dei software in ambiente Linux ed alcuni anche in ambiente Windows. Il fatto è che di software o componenti che la fanno da padroni rispetto alle alternative anche in ambiente GNU/Linux ce ne sono. Esempi? Il kernel stesso, tanto per citare di nuovo l'esempio precedente. Ok, argomentazione debole, allora ne elenco altri. La bash. L'interprete perl. Il server grafico X11. Python. Ghostscript. Gnuplot. Tutto l'ambiente GNU stesso con il compilatore gcc, gnu make e compagni. Tutta roba che in un computer destinato ad uso desktop viene installata di default e di cui difficilmente si potrebbe fare a meno.

Ora, a guardar bene, non è più così scontato che la "scarsa compatibilità" di GNU/Linux crei dei problemi ad eventuali virus. Per il semplice fatto che GNU/Linux è sufficientemente compatibile con altri sistemi GNU/Linux, almeno dal punto di vista di eventuali vulnerabilità, da poter offrire un substrato comune ad eventuali virus.

La comunità open source non ha interesse a sviluppare virus

Il lettore che mi ha segnalato questo punto di vista ha anche aggiunto una spiegazione più dettagliata. La riporto qui sotto:

' Secondo me l'asino casca qui, prima delle questioni tecniche che, ovviamente, potranno sempre dare una spiegazione ad un eventuale fenomeno di diffusione di virus su Linux. Credo che il punto sia il 'perchè'. Per quanto riguarda il mondo Windows, credo fermamente che la diffusione dei Virus, e dei relativi Anti-virus, sia un pò come qualcuno che ti infesta la casa di scarafaggi e poi viene a venderti l'insetticida ... '

In effetti questo punto di vista sul perché della diffusione dei virus su Windows è abbastanza diffuso, quindi avrei dovuto elencarlo fra gli altri fin dall'inizio. Ringrazio il lettore per avermelo segnalato.

Tuttavia questo punto di vista è tanto diffuso quanto errato. Chiaramente è un punto di vista, quindi tutti liberi di pensarla diversamente, ma il problema è che quand'anche condividessimo tutti questo modo di vedere le cose, ciò non significherebbe assolutamente che i virus per Linux non ci saranno mai. Esaminiamo i due casi, ovvero il caso in cui questa visione corrisponde a realtà ed il caso in cui invece la realtà sia diversa, dandone i motivi.

Parto dal mio punto di vista, ovvero secondo me la realtà è diversa. Io non penso che a produrre i virus siano gli stessi produttori di antivirus, o meglio può darsi che lo facciano perché i soldi non bastano mai, ma, anche in quel caso, potrebbero vivere dignitosamente semplicemente andando a caccia di virus non prodotti da loro stessi. Dico questo per un motivo semplice: io non ho mai lavorato per alcun produttore di antivirus, ma da giovane avrei venduto la palla sinistra in cambio della capacità tecnica di programmare un virus. E non per guadagnare poi i soldi con l'antivirus relativo, ma semplicemente per il piacere, la gloria, la soddisfazione di poter dire agli amici geek del quartiere: "quel virus l'ho fatto io". Quanti ragazzini come me esistevano al tempo? Quanti ne esistono ancora oggi? Il mondo è pieno di ragazzi con capacità tecniche sorprendenti e l'iter professionale tipico di questi soggetti è, nell'ordine: imparo a programmare, imparo a crackare i codici del decoder/dvd/bluray di turno, imparo a fare virus, imparo a crackare siti, mi arrestano o divento famoso in qualche altro modo analogo, vado a lavorare per una grande ditta che vende sicurezza informatica (se non mi hanno arrestato sarà una piccola ditta invece di una grande). Chiaramente non è tutto premeditato, ma è l'iter che molti attuali professionisti della sicurezza hanno seguito.

I black-hat sono tipici nerd che non hanno di meglio da fare che dimostrare al mondo quanto sono bravi. Quella è gente in età scolare che non ha bisogno di studiare per andare bene a scuola. Riesce e basta. E dimostrare al mondo che riescono a fare un virus anche per Linux è una sfida ancora più interessante, qualcosa di cui fregiarsi per tutta la vita.

Questo però è il mio punto di vista e può darsi che sia sbagliato. Diamo quindi per scontato, per un attimo, che il punto di vista segnalatomi sia quello giusto, ovvero sono le software house che fanno antivirus a produrre anche i virus.

Anche in questo caso non c'è da stare tranquilli. Nel momento in cui Linux diventasse il sistema desktop più diffuso, pensate che le software house attuali chiuderebbero? Pensate che licenzierebbero tutti e smetterebbero di vendere antivirus e distribuire relativi virus? Cosa impedirebbe loro di fare lo stesso anche per Linux? La comunità forse?

No, non credo. Se anche i virus fossero tutta opera delle software house, queste farebbero di tutto per restare sul mercato. La gente usa Linux e gli scarafaggi non si riproducono su Linux? Modifichiamo geneticamente gli scarafaggi in modo che si riproducano anche su Linux e continuiamo a fare soldi.

Beh, certo che a questo punto verrebbe da chiedersi: ma le software house che producono antivirus, come potrebbero vendere antivirus per Linux visto che c'è ClamAV che è gratuito? Argomentazione debole, il fatto di essere gratuito non è suffciente per diventare l'unico prodotto usato, basti guardare la situazione attuale fra Windows, MacOS e Linux.

Linux funziona su molte architetture eterogenee

Questa opinione mi è giunta dal buon Massimo the ex-President qualche tempo dopo che avevo scritto il resto di questo articolo. Nella sua email mi disse...

Stavo lavorando alla Sun Ultrasparc II da portare sabato prossimo in
esposizione e ho pensato, "se fai il virus che attacca anche CPU non
intel..... tocca veramente essere bravi".


Se ci pensi oggi come oggi ci sono in giro:
i386
AMD64
SPARC
POWERPC
IA64
EM64T
e altre 10 architetture minori.

Per un attimo, dopo aver ricevuto la sua email, mi venne spontaneo crogiolarmi nell'illusione che lui avesse ragione e decisi quindi che tutto l'allarmismo del presente articolo poteva tranquillamente essere archiviato nella tazza del bagno con un energica strattonata alla catena soprastante. La finestra del mio fedele KMail tagliava il messaggio esattamente fino a dove ve l'ho presentato qui sopra, ed io pensavo che sotto ci fossero solo i saluti. Più per abitudine che altro toccai la rotellina del mouse per far scorrere la scrollbar fino in fondo; il messaggio continuava:

La tendenza è di poter "ignorare" il problema CPU con GNU/Linux
mentre si sa già che la maggior parte dei sistemi "commerciali" gira
al massimo su i386 e AMD64 e IA64 (forse).

A questo punto accantonai l'idea della tazza e della catena perché quest'ultima frase dimostrava già da sola che il rischio esiste comunque. Ma il motivo vediamolo nel dettaglio.

La prima osservazione da fare è che, dal punto di vista di un virus, le architetture i386, AMD64 ed EM64T sono sostanzialmente la stessa architettura, il codice a 32bit x86 funziona allo stesso modo su tutte (supponendo di installare un sistema a 32 bit su tutte). Certo, quello che può cambiare fra queste tre è l'exploit, perché, per esempio, un buffer overflow con ritorno il libc deve probabilmente essere codificato in modo diverso per ognuna di esse (ma supponendo di aver installato un sistema a 32 bit su tutte non ne sarei così sicuro). Tuttavia questo non è un problema: il codice del virus può tranquillamente essere scritto per x86 generico e portarsi dietro tre payload differenziati per le tre architetture, se serve.

Ma veniamo all'ultima frase dell'email. Se la tendenza per il sistema è quella di ignorare il problema CPU (e lo è), cosa vieta ai virus di fare altrettanto? Il codice dei vari software sarà sempre più indipendente dall'architettura sottostante ed allo stesso modo anche le vulnerabilità, che immancabilmente ci saranno, saranno indipendenti dall'architettura hardware. A questo punto anche il codice del virus può essere indipendente: l'attacco avviene a livello del software applicativo, non a livello del sistema operativo. Questo scenario porta a tre conseguenze:

• il virus non ha bisogno di conoscere la CPU
• il virus è molto più semplice da scrivere
• il virus ha a disposizione strumenti molto più potenti delle singole istruzioni di CPU

Certamente non stiamo più parlando di virus della vecchia scuola, probabilmente saranno qualcosa di più simile ai macrovirus, ma senza bisogno di documenti con le macro: ormai ogni programma per il desktop capisce un qualche tipo di linguaggio di scripting, o nativamente oppure perché lo eredita dall'ambiente desktop in cui funziona.

Oltre a queste considerazioni, ne farei un'altra per non deludere i crackers della vecchia scuola: per leggi di mercato spietate quanto volete, una delle architetture hardware sarà sempre dominante sulle altre, in questo momento è x86, quale che sia nel futuro rimarrà comunque nella sua posizione di dominio sufficientemente a lungo da giustificare la scrittura di virus specifici ad essa dedicati. L'eventuale virus per linux verrà scritto solo per quell'architettura dominante e colpirà la maggior parte delle installazioni: il fatto che Linux funzioni su altre 20 architetture minori sarà irrilevante per la diffusione del virus. Potrete quindi continuare a scrivere i virus in LM ed avere un "bacino di utenza" sempre molto ampio...

Le argomentazioni maccheroniche

Arrivati a questo punto, sembra che la mia digressione sia seria. E infatti lo è. Che senso hanno allora le argomentazioni 3, 4 e 5 che ho elencato sopra? Mi riservo di togliervi la curiosità alla fine e di accantonare per ora quelle affermazioni, proseguendo a ritroso con l'affermazione numero 2.

I files eseguibili non stanno nella home

Il virus, ormai lo sappiamo tutti, è un programma che agisce fuori dal controllo dell'utente. Genera copie di sè stesso e le posiziona in punti dove possano essere eseguite, in modo da riprodursi il più possibile. Perché una copia del virus possa essere eseguita, deve trovarsi in un file eseguibile. In un sistema GNU/Linux, grazie alla separazione dei privilegi, l'utente di sistema che si usa per accedere alla rete, luogo pericoloso e pullulante di virus, è un utente che non ha i diritti necessari a modificare i files eseguibili del sistema, ma, al massimo, può modificare i files (eseguibili e non) presenti nella sua cartella home.

Partiamo allora dal presupposto che l'affermazione numero 2 sia corretta, ovvero che nella stragrande maggioranza dei casi non ci siano files eseguibili nella cartella home di un utente. Poi supponiamo che una delle applicazioni utilizzate dall'utente risenta di una vulnerabilità sfruttabile da remoto, del tipo che basta inviare all'utente un file da dare in pasto a quell'applicazione che magari usa la zlib, tanto per fare un esempio non casuale. Ora immaginiamo che questa vulnerabilità consenta all'attaccante di eseguire codice arbitrario sulla macchina vulnerabile, come in effetti accadeva col baco della zlib, con i diritti dell'utente che ha chiamato la zlib, quindi senza bisogno di tirare in ballo eseguibili con bit setuid, nè l'utente root. Quanto codice arbitrario ci vuole per creare uno script eseguibile nella home dell'utente stesso? Et voilà, ora la home dell'utente ha dentro un eseguibile. O forse una decina, dato che nulla vieta di farli. Certo che poi nessuno garantisce che questi files vengano effettivamente eseguiti.

Attenzione però, perché possiamo andare oltre. Supponiamo che questi eseguibili, che il virus crea, abbiano lo stesso nome di altri eseguibili di sistema. Questa ipotesi non è restrittiva in quanto nulla vieta al virus di chiamare il suo nuovo script con il nome "grep". Supponiamo anche che il virus metta questo nuovo script nella cartella "~/bin". Fino a qui sono tutte cose che il virus potrebbe fare a costo zero dal punto di vista del codice che deve contenere. Al virus resterebbe più solo da modificare il file ".bash_profile" per fare in modo che la cartella "~/bin" dell'utente compaia nel PATH prima di quelle di sistema (sulla mia Etch sarebbe sufficiente togliere un carattere a ".bash_profile" per ottenere tale effetto e sulla mia Ubuntu non serve fare nemmeno quello, ~/bin se esiste viene aggiunta automaticamente al PATH). Il risultato sarebbe:

• l'esistenza di un nuovo file eseguibile nella cartella ~/bin, con un nome uguale ad un eseguibile di sistema
• la variabile PATH modificata in modo che quell'eseguibile venga eseguito al posto di quello di sistema
• il contenuto di tale file eseguibile sotto il totale arbitrio del virus.

Un attimo, un attimo... la situazione sembra già preoccupante, ma c'è sempre spazio per un peggioramento... ".bash_profile"? Ho detto bene, vero? Allora non è vero che le home degli utenti non contengono quasi mai degli eseguibili. ".bash_profile" non ha il bit di esecuzione impostato, ma di fatto viene eseguito dalla bash ad ogni login. Ed esiste praticamente sempre. Anche se non esistesse, al virus (codice arbitrario eseguito grazie al baco della zlib di turno) basterebbe crearlo. Inoltre il fatto di non avere il bit di esecuzione impostato permette al virus di mettere codice eseguibile in un file che non è ritenuto eseguibile, quindi anche l'eventuale opzione noexec in fase di mount della /home viene allegramente aggirata dal virus. Ora la situazione che si delinea è decisamente peggiore:

• il virus ha dunque un posto dove mettersi
• lì è sicuro di essere eseguito
• il tutto sfruttando una qualsiasi vulnerabilità di un qualsiasi software bacato per il desktop
• al virus non serve scalare i privilegi fino a root, nemmeno per riprodursi.

Molto bene, direi che l'affermazione 2 è confutata.

Nessuno usa Linux

Siamo alla numero 1. Sostanzialmente dice che i virus su Linux non ci sono perché è molto più interessante scrivere un virus che infetti il 95% dei desktop, piuttosto che uno che infetti solo il restante 5%. Inconfutabile. Ma è solo questione di tempo. Nel momento in cui i desktop GNU/Linux serviranno una percentuale più alta di utenti, diventerà interessante scrivere un virus anche per questi sistemi. E sperare che GNU/Linux sul desktop non si diffonda non è una soluzione accettabile.

Il cacio sui maccheroni

Infine abbiamo le affermazioni 3, 4 e 5, tutte fatte da utenti di sistemi GNU/Linux e/o MacOS X. Ovviamente non sto a sprecare bytes per confutarle, ma voglio solo spiegare il perché della loro presenza qui. Queste affermazioni dimostrano che il vero problema, quando si parla di sicurezza, è il fattore umano. Se esiste gente in grado di spacciarsi per esperto e nel contempo dire certe cose prive di senso, significa che i virus avranno sempre spazio d'azione. Nel momento in cui questi sedicenti esperti di sicurezza (o almeno che si vendono per tali, visto che stanno a somministrare pillole di saggezza) dovranno affrontare sul campo il problema della sicurezza informatica, sapremo che sarà di nuovo ora per i veri esperti di fare il loro lavoro e far capire, questa volta agli ignari utenti di GNU/Linux, che la sicurezza non è un prodotto ma un processo, che non basta un antivirus per dormire sonni tranquilli e non basta una password difficile quanto volete. E non basta usare GNU/Linux invece di altri sistemi.

No, non è un'utopia. È solo questione di tempo.