[Copyright Notice]

Virus et anti-virus sur Linux - Chapitre 2
Les Virus


2.1 Définition

Le virus informatique fonctionne de manière analogue au virus biologique. Il va se dupliquer dans un programme « hôte » lorsqu'une partie de code d'un autre programme « infecté » par ce virus est exécutée. C'est le plus souvent un segment de code exécutable ou de script qui va se greffer à l'intérieur de programmes ou de documents utilisant des scripts. Lors de l'insertion de ce segment de code dans le programme, le virus va aussi modifier la structure de celui ci de telle façon que le code infecté puisse être exécuté en premier lieu.


2.2 Types de Virus

Les virus informatiques possèdent plusieurs formes, et fonctionnent tous de façons différentes en fonction de leurs types. Tous les virus ne sont pas destructeurs, leurs actions sont aussi diverses que leurs nombres. Ils peuvent se placer aussi bien sur des zones particulières d'un disque dur ou d'une disquette, que sur le système de fichiers disponible. On classifie généralement les virus par rapport à leur mode de fonctionnement :


2.3 Les effets

Les effets dépendent de la nature du virus, cela peut aller du petit message qui va apparaître lors du démarrage de la machine à l'effacement complet des données présentes sur le disque dur. Il faut cependant considérer tous les virus comme dangereux. En effet le virus le moins dangereux en apparence peut-être une menace pour l'homme, par exemple dans le cas d'un appareil de surveillance dans un contexte hospitalier, un virus qui bloque la machine en affichant un message jusqu'à ce qu'une touche soit pressée, peut être fatal.

On peut définir trois états ou phases pour les virus :

Un virus peut se placer aussi bien dans un programme que dans le BIOS d'une machine (c'est l'interface entre le système d'exploitation et la machine, on le trouve plus communément sous la forme d'une mémoire flash, intégrée à la carte mère) ou encore dans les secteurs de démarrage des disquettes ou des disques durs.

Les virus s'attaquent tout particulièrement aux fichiers exécutables binaires, par conséquent nous allons nous intéresser au format de ces fichiers pour comprendre comment les virus les infectent. Ils existent plusieurs formats de fichiers exécutable et nous nous intéresserons plus particulièrement au format « PE » (Portable Executable) utilisé par le système Windows et au format ELF (Executable and Linkable Format) utilisé par le système GNU/Linux.


2.3.1 Format des fichiers exécutables binaires

Les fichiers exécutables, quelque soit leur format, sont composés de plusieurs parties (voir figure 2.1) qui vont permettre au programme correspondant de se dérouler sans problème. On peut les découper en cinq parties principales :

Ces deux formats proposent chacun une approche différente du chargement des bibliothèques de fonctions. Le format ELF stocke les fonctions dont il a besoin ainsi que les bibliothèques, en revanche il ne stocke pas dans quelle bibliothèque se trouvent les fonctions utilisées. Le format PE est moins flexible à ce niveau là, mais est plus résistant aux erreurs éventuelles. Par exemple, un programme nécessite la fonction A contenue dans la bibliothèque A et la fonction B qui contenue dans la bibliothèque B.

Si une nouvelle version de la bibliothèque A vient à définir sa propre fonction B :


2.3.2 Organisation de la mémoire

La mémoire est un des composants majeur pour les différents systèmes d'exploitation. Il existe deux types de systèmes :

Nous allons nous intéresser à ces systèmes car certains virus opèrent dans la mémoire.


2.3.2.1 Les systèmes sans mémoire virtuelle

Ces systèmes proposent trois fonctions qui permettent une gestion de la mémoire :

Ces fonctions ne sont pas utilisées par la plupart des programmes. Lorsqu'un programme est exécuté, le système va lui donner toute la mémoire disponible. Les systèmes DOS et Windows (95 et 98) fonctionnent sur ce mode de gestion.

Tous les programmes évolués qui se terminent et restent résidants en mémoire, qui appellent à d'autres programmes ou qui exécutent des actions de gestion de mémoire, utilisent ces fonctions.

Généralement, ces programmes rendent toute la mémoire qui leur a été affectée et qu'ils n'utilisent pas. Ils effectuent des opérations d'attribution, de restitution en fonction de leurs besoins.

Cette gestion de la mémoire implique que tous les programmes exécutés partagent le même espace mémoire suivant la disponibilité de celui ci. Tous les programmes ont un accès en lecture et en écriture dans la mémoire.

Dans une telle situation il est tout à fait permis à un programme d'en parasiter un autre dans l'espace d'adressage du système d'exploitation, en détournant les appels systèmes afin d'accéder à la mémoire du système d'exploitation.


2.3.2.2 Les systèmes avec mémoire virtuelle

Ces systèmes doivent exécuter le plus de programmes possible. Ces programmes doivent s'exécuter sans mutuellement s'interférer. Pour cela ces systèmes leur font croire qu'ils disposent du processeur et d'un grand espace mémoire. Ils « virtualisent » la mémoire.

Chaque programme possède alors son propre espace d'adressage virtuel, et ne peut accéder uniquement qu'à cet espace. Ils sont complètement indépendant les uns des autres, par conséquent l'exécution d'un programme ne peut affecter le comportement des autres.

Les mécanismes de gestion de mémoire virtuelle, permettent de protéger la mémoire physique contre les accès en écriture. Ainsi les programmes et les données sont protégés contre la récriture par des applications malicieuses.

Dans ces systèmes, seul le noyau du système possède un accès aux deux types de mémoire (physique et virtuelle), de même qu'il est le seul à pouvoir effectuer les opérations de lecture et d'écriture sur la mémoire physique.


2.3.3 Infection des programmes

Il existe trois méthodes d'infection de fichiers exécutables. Chacune d'entre elles emploie des techniques spécifiques pour que le virus soit exécuté en premier lieu :


2.4 Analyse des virus et pseudo-virus sous GNU/Linux

Un petit nombre de virus existant sous GNU/Linux ont été détectés (« Bliss », « File », « VIT », « SIILOV » pour ne citer qu'eux), mais il faut savoir qu'à l'heure actuelle ces virus ne peuvent pas se propager de manière aussi importante que sous d'autres systèmes d'exploitation (Microsoft Windows, par exemple) comme ont pu le faire des virus tel que « Melissa », ou « ILoveYou » et cela pour de multiples raisons. Dans la suite, nous dégagerons les aspects techniques des aspects humains, nous présenterons le noyau qui de part son rôle central est considéré comme la pièce critique du système, nous exposerons aussi la notion de « droits » sur les composants logiciels et matériels, nous parlerons alors des virus existants et des failles potentielles qui peuvent se présenter, nous présenterons les protections existantes pour cela et nous finirons par des exemples de virus.


2.4.1 Le noyau Linux

Aujourd'hui, le noyau ne possède pas de failles connues qui puissent être exploitables par des virus pendant une période suffisamment longue pour permettre une propagation de ceux-ci. En effet, le mode de développement du noyau est tel que lorsqu'une faille est détectée, elle est immédiatement soumise à la communauté des développeurs de logiciel libre, via les listes de diffusion du noyau (linux-kernel@vger.rutgers.edu) et la liste de diffusion de bogues 'bugtrag' (bugtraq@securityfocus.com). Cela a été le cas par exemple en juillet 1999 lorsque Solar Designer avait découvert un bogue dans le comportement du noyau lorsque le support de plus de 1 Go de mémoire physique a été introduit dans ce dernier. Il était alors possible a un programme exécuté dans le mode « utilisateur » d'écrire dans la mémoire physique du système. Il a proposé un correctif en même temps qu'il annonçait la présence de cette faille.

Le noyau protège le matériel en faisant fonctionner les applications dans le «mode utilisateur», il s'agit d'un mode particulier du processeur qui évite l'accès direct au matériel par les applications, en dehors de certaines parties de la mémoire et des registres du processeur. Les virus BIOS n'auront d'effet sur la machine que jusqu'à la fin de l'initialisation du noyau Linux, car celui ci n'utilise pas les appels systèmes fournit par le BIOS, mais ses propres appels.

Un virus qui exploiterait une faille d'une version d'un noyau ne serait pas efficace sur toutes les distributions. Elles n'utilisent pas forcément les mêmes options les de la compilation de ce dernier.


2.4.2 La notion de « droits »

Le système GNU/Linux hérite des aspects sécuritaires d'Unix, comme la notion de « droits » sur ses composants aussi bien logiciels que matériels. Chaque utilisateur ne peut effectuer des opérations que sur une zone du système, en l'occurrence le répertoire qui lui est dédié, il n'a pas un accès total à l'ensemble des composants du système sauf si la personne responsable de cette partie ne lui en ait donné l'accès.

Cette notion se traduit de la manière suivante, si jamais un utilisateur venait à exécuter un programme contaminé, seul son environnement serait concerné, le système protégé par les « droits » ne serait pas touché.

Elle permet de construire un groupe de personnes restreint ayant les compétences nécessaires pour pouvoir administrer les machines comme il se doit. Ces personnes doivent maîtriser généralement tous les aspects de la sécurité du système, aussi bien sur la couche noyau, que sur les couches applicatives. Elles se tiennent au courant, sur les sites spécialisés, des failles qui ont été découvertes et appliquent les mises à jour logicielles adéquates de manière rapide.


2.4.3 Existence des virus

Malgré les aspects sécuritaires évoqués précédemment, il existe cependant des virus. Des documents sont disponibles en ligne sur Internet qui expliquent comment exploiter le format ELF (Executable and Linking Format) des fichiers exécutables par exemple, (http://www.big.net.au/~silvio/unix-viruses.txt document écrit par Silvio Cesare qui aurait déjà écrit 3 virus pour GNU/Linux) pour y inclure des fragments de code nuisibles dans le sens où ils ne font pas partie du code d'origine. Cette méthode impose d'avoir un virus de petite taille puisque l'idée est d'exploiter l'espace entre le segment texte et le segment de données d'un programme.

Parmi la liste de classification des virus, nous allons voir pourquoi ces virus ne peuvent être présents ou fonctionnels sur le système GNU/Linux

Le fait de ne pas avoir une centralisation du développement, comme c'est le cas pour beaucoup d'éditeurs de logiciels, permet d'obtenir un correctif très rapidement. Ce correctif (patch) est souvent disponible moins de 24 heures après l'annonce de la découverte d'une faille. Une nouvelle annonce est alors faite sur des sites de sécurité tels que « Security Focus » (http://www.securityfocus.com/), « Security Portal » (http://www.securityportal.com/). Cette information est alors relayée aux utilisateurs via des sites d'informations tel que « Slashdot » (http://www.slashdot.org/) ou bien en français « Linuxfr » (http://www.linuxfr.org/) et sur les sites des diverses distributions GNU/Linux (http://www.debian.org/, http://www.redhat.com/, http://www.mandrake.com/, etc.)

De plus l'existence de programmes dont on ne possède pas le code source comme Netscape Communicator ou encore StarOffice peut permettre une contamination. Ces programmes incluent des interpréteurs de langage qui peuvent avoir des failles de sécurité importantes. Netscape Communicator par exemple, possédait une faille dans l'interpréteur Java inclut dans les versions 4.0x qui permettait à une applet de désactiver toutes les sécurités de l'interpréteur rendant le système vulnérable à toute forme d'infection. StarOffice n'est pas capable d'interpréter les macros de documents écrit avec la suite bureautique de Microsoft ce qui le protège des macros-virus écrit dans le langage macros de cette société. Il possède cependant son propre langage de macros qui pourrait aussi véhiculer des virus écrit spécifiquement pour celui ci.

L'inconvénient avec ces programmes vient de la dépendance envers les sociétés qui les ont édités. L'arrivée d'un correctif peut s'avérer insuffisante, par exemple le correctif que la société Netscape avait proposé pour résoudre le bogue s'est avéré inefficace. La solution temporaire était de désactiver la possibilité d'exécuter du Java avec son navigateur.


2.4.4 Les protections possibles

Les systèmes GNU/Linux possèdent d'autres aspects qui permettent de contrôler la cohésion du système et surtout sa possible infection. Dans les distributions Redhat et Debian, les responsables de paquets utilisent un système de signature qui permet d'en assurer l'origine.

L'authenticité du paquet, et par conséquent de son contenu, est alors garantie par la confiance à laquelle peut prétendre ce-dit développeur. La signature peut prendre plusieurs aspects, soit par l'utilisation d'une somme de contrôle, qui varie quelque soit la modification effectuée sur le fichier, soit par l'utilisation d'une clé publique de chiffrement, unique pour chaque personne.

Ces méthodes ont des avantages et des inconvénients, mais en dépit de cela, elles restent garantes de l'intégrité des paquets installés sur le système. On ne leur connaît pas encore de failles. Nous présenterons tout d'abord les méthodes utilisées puis un exemple d'application pour les distributions Debian GNU/Linux et RedHat Linux.


2.4.4.1 La somme de contrôle

La somme de contrôle (« checksum ») est une méthode qui permet de facilement déterminer si un fichier reçu est bien identique à l'origine. Elle est souvent utilisée par des protocoles de transmission et permet ainsi de déterminer que le document original a bien été transmis dans sa totalité. Des dérivés de cette méthode sont apparues pour permettre entre autre de déterminer que le fichier que l'on a sous les yeux correspond bien à celui d'origine. En effet les premiers algorithmes se contentaient de compter le nombre de bits envoyés et vérifiaient que ce nombre était bien le même en réception ce qui ne garantit pas toujours le résultat :

             $ echo "ceci est un exemple" > exemple_1
             $ echo "ceci est une xemple" > exemple_2
             $ sum -s exemple_1 exemple_2
             1821 1 exemple_1
             1821 1 exemple_2
Un des outils utilisés pour cela se nomme « sum » (utilisé dans notre précédant exemple avec une option pour obtenir une somme simple). Voici le résultat de cette commande en utilisant un algorithme qui effectue des décalages sur 16 bits lors de la somme sur les mêmes fichiers, on voit clairement que la moindre petite modification effectuée sur le fichier génère un résultat très différent :
             $ sum exemple_1 exemple_2
             51230     1 exemple_1
             33566     1 exemple_2
Cependant, cet algorithme étant cyclique, il est tout à fait possible d'avoir deux fichiers très différents qui retournent le même résultat par cette commande, puisqu'elle renvoie une valeur comprise entre 0 et 2^16 Des algorithmes plus complexes qui utilisent un mélange de chiffrement sur 128 bits, de sommes de bits avec des décalages sur 32 bits ont été élaborés pour obtenir une valeur de sortie que l'on peut considérer comme unique, compte tenu du nombre important de valeurs possible (2^128).


2.4.4.2 La clé publique de chiffrement

La clé de chiffrement est un moyen efficace pour garantir l'origine d'un document. L'auteur possède une clé privé et une clé publique, et distribue la seconde tout en gardant secrète la première. Toute personne peut alors lui écrire en utilisant sa clé publique pour crypter le message que lui seul sera en mesure de décrypter avec sa clé privée.

Dans ce principe ce n'est pas la même clé qui crypte et décrypte les messages, on appelle cela de la cryptographie asymétrique. Elle s'oppose à la cryptographie symétrique où la même clé est utilisée pour crypter et décrypter.

La difficulté dans la deuxième méthode est de transmettre la clé de manière sécurisée. La cryptographie asymétrique repose sur des calculs mathématiques complexes utilisant les nombres premiers. Le produit de deux nombres premiers est facile, par exemple 1973 et 379 nous donne 747767. Mais il est plus difficile de factoriser, c'est-à-dire de trouver 1973 et 379 à partir de 747767. C'est sur ce principe mathématique que repose la cryptographie asymétrique.

Le premier système de cryptographie à clé publique a été proposé en 1978 par Ronald Rivest, Adi Shamir et Leonard Adleman, trois chercheurs du MIT, une université américaine, qui ont donné leur nom au système baptisé RSA. C'est sur cette méthode RSA que sont fondés de nombreux logiciels de chiffrement et la plupart des logiciels de paiement sécurisé.


2.4.4.3 Signature de paquet Debian

L'intégrité d'un système Debian repose avant tout sur la base du « ring of trust », c'est-à-dire que tous les développeurs sont identifiés, et connaissent au moins physiquement un autre développeur Debian. En cas de problème avec un paquet, il est tout à fait possible de se retourner vers une personne physique (chose qui est plus difficile sur les autres systèmes car n'utilisant pas ce principe). De plus, chaque paquet est signé par la clé privée PGP (Pretty Good Privacy) du développeur, il s'agit d'une mise en application du principe de clé publique de chiffrement qui permet à des personnes de s'échanger des documents de manière sécurisée. Cela ajoute un gage supplémentaire de sécurité puisque cette clé est considérée unique, en effet la probabilité pour obtenir deux clés identiques est très faible.

Il faut cependant noter un manque concernant la possibilité de vérification de l'ensemble d'un système. En effet, il n'est pas possible de s'assurer que le système n'a pas été infecté, à moins d'effectuer un grand nombre de manipulations. Certains paquets incluent cependant la liste de fichiers qu'ils contiennent avec la somme de contrôle correspondante, générée avec l'outil md5sums. Cela est encore loin d'être satisfaisant, et ce manque devrait être corrigé dans les prochaines versions des paquets Debian, même si les développeurs ne sont pas encore arrivés à définir un mode complètement sécurisé.


2.4.4.4 Signature de paquet Redhat

La méthode de signature utilisée par Redhat est la seule méthode permettant de contrôler rapidement si un système a été infecté après son installation. En effet, chaque paquet Redhat possède la liste des fichiers qu'il contient avec la somme de contrôle correspondante, générée avec l'outil md5sum. Cette liste est placée dans une base de données ce qui permet de rapidement vérifier la cohésion du système.

Le problème avec ce système est que si cette base venait à être corrompue, il ne serait plus possible de vérifier l'intégrité du système.

Un autre problème vient du fait que toutes les personnes générant des paquets Redhat ne sont pas déclarées de manière sûre, ce qui signifie qu'un paquet peut être modifié avant l'installation, voire qu'une personne peut créer un paquet qui va modifier la base contenant les signatures et les falsifier à notre insu, ce qui rend toutes les vérifications caduques.


2.5 Quelques exemples de virus


2.5.1 Le virus « ILoveYou »

La présence de droits aurait sûrement limité la propagation du virus « ILoveYou ». En effet, les utilisateurs de Windows ont tous les droits sur le système et ont ainsi pu infecter tous les fichiers aux formats MP3 et JPEG présents sur la machine. « ILoveYou » est un exemple intéressant de virus car il combine plusieurs techniques :

Des imitations de ce virus ont très rapidement circulé. Un nouveau virus a ajouté l'attribut du polymorphisme (il change le sujet du courrier électronique à chaque envoi). Il se nomme « VBS.NewLove.A » et est plus destructeur que « ILoveYou ». Ce virus n'affecte pas les systèmes GNU/Linux.


2.5.2 Le virus « SIILOV »

Ce virus UNIX utilise deux méthodes d'infection qui sont peu communes sous cet environnement :


2.6 Point sur les virus

Les virus existants sur le système GNU/Linux ont une action relativement restreinte quelque soit leur nature, cela avant tout parce que le système a repris et amélioré des principes de sécurité hérités du système UNIX.

Ce système a été conçu dès le départ dans une optique de réseau, et a été développé autour du réseau, prenant en compte la problématique de la sécurité de chaque utilisateur, ce qui diminue grandement la possibilité de voir des virus se développer.

La nature même des logiciels libre disponibles sur cet environnement fait qu'il est très difficile de cacher une information à un groupe important de personne (code est accessible par tous).

Enfin la communauté des développeurs qui s'est fait un point d'honneur d'avoir un système fiable sur lequel elle peut travailler sans être importunée d'aucune sorte, est très réactive aux failles détectées et s'empresse de les corriger.


[Copyright Notice]

Virus et anti-virus sur Linux
Tony Bassette tony.bassette@alcove.fr