PROCÉDÉ POUR EMPÊCHER L'EXÉCUTION DE LOGICIELS MALVEILLANTS AU SEIN D'UN
SYSTÈME INFORMATIQUE
CONTEXTE DE L'INVENTION
1. Domaine technique
La présente invention concerne la prévention contre les logiciels malveillants en général et, en particulier, un procédé destiné à empêcher l'exécution de logiciels malveillants au sein d'un système informatique.
2. Description de la technique apparentée Les logiciels malveillants, tels que les virus informatiques, peuvent pénétrer dans un système informatique de nombreuses façons. Par exemple, ils peuvent pénétrer dans le système informatique par l'intermédiaire d'un disque qui est destiné à être inséré dans le système informatique ou ils peuvent pénétrer par l'intermédiaire d'un e-mail qui est destiné à être ouvert par un utilisateur du système informatique. Les logiciels malveillants peuvent occasionner des problèmes au système informatique s'ils sont exécutés au sein du système informatique. Par exemple, la sécurité informatique peut être compromise ou des fichiers au sein du système informatique peuvent être détruits.
Certains types de logiciels malveillants peuvent facilement être détectés à l'aide de techniques de détection simples, tel qu'un balayage pour localiser une chaîne de recherche. Toutefois, ce type de processus de détection peut également facilement être déjoué en convertissant le code malveillant par compression ou cryptage, contournant ainsi les filtres à balayage. Une autre approche pour la détection des logiciels malveillants consiste à exécuter un programme tout en tentant d'intercepter des actions malveillantes pendant l'exécution du programme. Cette technique, connue sous le nom d'inhibition de comportement, présente un certain nombre de désavantages. En dépit de la tentative d'intercepter des actions malveillantes, le programme peut néanmoins occasionner des dommages au système informatique. Qui plus est, le mécanisme d'inhibition de comportement ne peut typiquement pas voir un journal complet d'actions lorsqu'il effectue une détermination d'inhibition. Donc, le mécanisme d'inhibition de comportement peut prendre des décisions d'inhibition sous-optimales, ce qui signifie que des programmes inoffensifs peuvent être inhibés tandis que des programmes nuisibles peuvent être autorisés à s'exécuter.
Encore une autre approche pour la détection des logiciels malveillants consiste à émuler du code suspect dans un environnement isolé d'un système informatique de telle sorte que le système informatique soit protégé des actions malveillantes du code suspect. Un inconvénient de l'émulation est que bien qu'elle puisse protéger des parties du système informatique des attaques de virus, elle n'est pas elle-même protégée. De plus, des données peuvent être contaminées, ce qui mène à une brèche dans l'environnement d'isolement.
Par conséquent, il serait souhaitable de mettre à disposition un procédé amélioré pour empêcher l'exécution de logiciels malveillants au sein d'un système informatique.
RESUME DE L'INVENTION En accord avec un mode de réalisation préféré de la présente invention, une permutation est effectuée sur un sous-ensemble d'instructions au sein d'un programme d'application pour donner une séquence permutée d'instructions avant toute exécution réelle du programme d'application sur un système informatique. Un numéro de séquence de permutation de la séquence permutée d'instructions est mémorisé dans un tableau de pointeurs d'instructions permutées. La séquence permutée d'instructions est exécutée dans un module d'exécution capable de traduire la séquence permutée d'instructions en un langage machine réel d'un processeur au sein du système informatique selon le numéro de séquence de permutation de la séquence permutée d'instructions mémorisé dans le tableau de pointeurs d'instructions permutées.
Un procédé destiné à empêcher l'exécution de logiciels malveillants au sein d'un système informatique comporte la compilation croisée d'un programme d'application pour donner un jeu de code compilé de façon croisée dudit programme d'application avant toute exécution réelle dudit programme d'application sur ledit système informatique. Le procédé comporte aussi l'exécution dudit jeu de code compilé de façon croisée dudit programme d'application dans un module d'exécution capable de reconnaître et de traduire ledit jeu de code compilé de façon croisée dudit programme d'application en un langage machine réel d'un processeur au sein dudit système informatique.
Toutes les caractéristiques et les avantages de la présente invention deviendront manifestes dans la 30 description écrite détaillée qui suit.
DESCRIPTION SUCCINCTE DES DESSINS
L'invention elle-même, ainsi qu'un mode d'utilisation 35 préféré, des objets supplémentaires et des avantages de celle-ci, seront mieux compris en faisant référence à la description détaillée qui suit d'un mode de réalisation illustratif lorsqu'elle est lue conjointement avec les dessins joints, où :
la Figure 1 est une vue conceptuelle d'un procédé destiné à empêcher l'exécution de logiciels malveillants au sein d'un système informatique, en accord avec un mode de réalisation préféré de la présente invention ;
la Figure 2 est un diagramme synoptique d'un environnement informatique dans lequel un mode de réalisation préféré de la présente invention est incorporé ; et
les Figures 3a à 3e illustrent une séquence dans laquelle des instructions sont en cours de permutation, en accord avec un mode de réalisation préféré de la présente invention.
DESCRIPTION DETAILLEE D'UN MODE DE REALISATION PREFERE Typiquement, il existe plusieurs niveaux de jeux d'instructions au sein d'un système informatique. Le premier niveau (le plus bas) est celui des instructions au niveau machine et le deuxième niveau est celui des instructions d'interface binaire d'applications du système d'exploitation. Au deuxième niveau, le système d'exploitation a rendu abstraites les instructions du niveau machine pour les rendre plus faciles à comprendre. Le troisième niveau est celui des instructions au niveau macro-commande, où une application a rendu encore plus abstrait le contrôle du système informatique pour permettre une facilité de programmation.
Comme de nombreuses techniques ont été dédiées à la protection des deuxième et troisième niveaux d'instructions, la présente invention est uniquement orientée vers la protection du premier niveau d'instructions, en particulier à un moment où celui-ci 4 est le niveau utilisé par de nombreux virus informatiques.
De façon générale, il est improbable, sinon impossible, d'écrire un programme de niveau machine qui puisse être exécuté au sein d'un système informatique sans connaître le jeu d'instructions au niveau machine d'un processeur au sein du système informatique. De plus, une installation de logiciel sur un système informatique impose au logiciel de comprendre en premier lieu le jeu d'instructions du système informatique sur lequel il est en train d'être installé. Ainsi, en accord avec un mode de réalisation préféré de la présente invention, un programme d'application est initialement transformé en un jeu de code compilé de façon croisée du programme d'application, et le jeu de code compilé de façon croisée du programme d'application est alors exécuté au sein d'un module d'exécution capable de reconnaître le jeu de code compilé de façon croisée du programme d'application.
En référence à présent aux dessins et en particulier à la Figure 1, on illustre une vue conceptuelle d'un procédé destiné à empêcher l'exécution de logiciels malveillants au sein d'un système informatique, en accord avec un mode de réalisation préféré de la présente invention. Comme représenté, un système informatique 10 comprend un module de transformation 11 et un module d'exécution 12. Tout programme d'application qui doit être exécuté au sein du système informatique 10 doit subir un processus d'installation. Au cours du processus d'installation, un utilisateur du système informatique 10 peut décider si un programme d'application doit ou non être installé au sein du système informatique 10. Si l'utilisateur décide que le programme d'application doit être installé au sein du système informatique 10, le programme d'application est alors envoyé au module de transformation 11 dans lequel le programme d'application sera transformé en un jeu de code compilé de façon croisée du programme d'application. Le jeu de code compilé de façon croisée du programme d'application peut ensuite être exécuté au sein du module d'exécution 12 capable de reconnaître et de traduire le jeu de code compilé de façon croisée du programme d'application dans le langage machine réel du processeur.
Sans passer par le processus d'installation, un programme d'application ne pourra pas être exécuté par le module d'exécution 12. Par exemple, comme représenté sur un chemin illicite 15, même si un programme de virus s'est faufilé sans avoir été détecté par un utilisateur et a été placé au sein du système informatique 10 à l'insu de l'utilisateur, le programme de virus ne peut toujours pas être exécuté par le module d'exécution 12 car le programme de virus n'a pas subi le processus d'installation. A ce titre, le système informatique 10 est à l'abri des dommages potentiels qui auraient pu être engendrés par le programme de virus.
En pratique, le module de transformation 11 et le module d'exécution 12 doivent être isolés l'un de l'autre. En fait, le module d'exécution 12 doit être empêché d'accepter du code de toute source autre que le module de transformation 11.
En référence à présent à la Figure 2, on illustre un diagramme synoptique d'un environnement informatique dans lequel un mode de réalisation préféré de la présente invention est incorporé. Comme représenté, un système informatique 20 comprend une structure matérielle 21, un gestionnaire de machine virtuelle (VMM) ou hyperviseur 22 et des machines virtuelles 23a-23b. Les machines virtuelles 23a et 23b sont de préférence situées dans des partitions séparées de telle sorte que toute exécution au sein de la machine virtuelle 23a est isolée de la machine virtuelle 23b ou vice versa. Le VMM 22 contrôle toutes les communications entre les machines virtuelles 23a et 23b. De plus, le VMM 22 peut communiquer directement avec la structure matérielle 21. La structure matérielle 21 comprend des structures connues telles que des processeurs, des registres, des unités de gestion de la mémoire, des dispositifs de mémoire, des dispositifs d'entrée/sortie, etc.
Un système d'exploitation et de multiples programmes d'application peuvent être exécutés concurremment au sein de chacune des machines virtuelles 23a-23b. Par exemple, un système d'exploitation 24 et un programme d'application 25 sont exécutés au sein de la machine virtuelle 23a, tandis qu'un système d'exploitation 26 et un programme d'application 27 sont exécutés au sein de la machine virtuelle 23b.
Bien que cela ne soit pas obligatoire, le système d'exploitation 24 peut être différent du système d'exploitation 26. Par exemple, le système d'exploitation 24 peut être un système d'exploitation libre Linux, tandis que le système d'exploitation 26 peut être le système d'exploitation Windows produit par la Société Microsoft. De façon analogue, le processeur sous-jacent émulé par la machine virtuelle 23a peut également être différent du processeur sous-jacent émulé par la machine virtuelle 23b. Par exemple, le processeur sous-jacent émulé par la machine virtuelle 23a peut être un processeur Pentium produit par la Société Intel, tandis que le processeur sous-jacent émulé par la machine virtuelle 23b peut être un processeur PowerPC produit par la Société International Business Machines.
Chacune des machines virtuelles 23a-23b, ce qui inclut son système d'exploitation et ses programmes d'application associés, fonctionne au niveau de l'utilisateur. Lorsque le VMM 22 utilise l'exécution directe, le VMM 22 est réglé en mode dit utilisateur (c'est-à-dire avec des prérogatives réduites) de telle sorte qu'aucune des machines virtuelles 23a-23b ne puisse accéder directement aux divers registres privilégiés qui contrôlent le fonctionnement de la structure matérielle 21. Au lieu de cela, toutes les instructions privilégiées seront piégées dans le VMM 22.
Sur la Figure 2, on montre que la machine virtuelle 23a comprend un compilateur croisé 28 destiné à effectuer les compilations croisées initiales des programmes d'application. De plus, on montre que la machine virtuelle 23b comprend un module d'exécution 29 destiné à exécuter le code compilé de façon croisée des programmes d'application. Les compilations croisées sont effectuées de préférence via un algorithme de permutation et les résultats sont mémorisés dans un tableau 30 de pointeurs d'instructions permutées. Le tableau 30 de pointeurs d'instructions permutées comprend des entrées multiples de séquences de permutation. Chacune des séquences de permutation est associée à un jeu de code compilé de façon croisée d'un programme d'application. Toutes les séquences de permutation au sein du tableau 30 de pointeurs d'instructions permutées ont des chances d'être différentes les unes des autres, bien qu'elles n'aient pas l'obligation d'être différentes les unes des autres. Sur la Figure 2, on représente le tableau 30 de pointeurs d'instructions permutées comme étant placé au sein du VMM 22 ; toutefois, le tableau 30 de pointeurs d'instructions permutées peut également être placé au sein de la machine virtuelle 23a, pourvu qu'il soit également accessible à la machine virtuelle 23b.
Un procédé illustratif pour effectuer des permutations se déroule comme suit. Premièrement, un sous-ensemble d'instructions n est sélectionné parmi un groupe d'instructions à des fins de permutation. Toutes les permutations d'instructions ne seraient pas de la même utilité. Par exemple, des permutations d'instructions identité ne seraient d'aucune utilité. Aussi certaines instructions machine (telles qu'une instruction JUMP) devraient-elles être identifiées comme des instructions critiques afin de s'assurer que toutes les instructions critiques soient permutées.
Il existe plusieurs façons de générer des permutations. Un des procédés consiste à utiliser une fonction basée sur un hachage ou un cryptage de telle sorte que chaque instruction dans un segment de données possède une conversion différente, c'est-à-dire H (Al) , H (A2) ,..., H(Ai), où H est la fonction basée sur un hachage et A est une instruction. Le problème posé par l'utilisation d'une fonction basée sur un hachage ou un cryptage est que, d'un point de vue général de compilation, les mêmes instructions peuvent avoir des résultats de hachage différents. Par exemple, l'instruction A5 et l'instruction A9 peuvent être la même instruction, mais H(A5) n'est pas nécessairement égale à H(A9) . Un autre procédé consiste à faire appel à une fonction de conversion différente P(A), où P est la permutation et A est l'instruction, ce qui génère P1(A), P2(A),..., Pn(A). Ce procédé donne un résultat de compilation croisée plus prévisible, puisque P1(J), où J est l'instruction donnée, doit être la même quel que soit l'endroit où elle apparaît dans le segment de code. Une séquence de permutation impose la façon dont le sous-ensemble d'instructions n doit être permuté ou transformé. Chaque séquence de permutation peut être vue comme une entrée présentant des emplacements multiples, chaque emplacement devant être occupé par un numéro d'instruction. Afin de générer une rième séquence de permutation, un nombre aléatoire compris entre 0 et n!-1 est initialement choisi. Par exemple, si le sous-ensemble d'instructions n à permuter est au nombre de 5 (ce qui signifie qu'il existe 5!=120 séquences de permutation), un nombre aléatoire 101 peut être choisi entre 0 et 5!-1 comme la 101ème séquence de permutation.
La position Pos de l'emplacement du premier numéro d'instruction est indiquée par le dividende du nombre aléatoire choisi r divisé par (n-1)!, comme suit : Pos = r (n-1)! Le reste de la division remplace le nombre aléatoire choisi r pour la détermination de la position Pos de l'emplacement du numéro d'instruction suivant jusqu'à ce que tous les emplacements soient occupés par des numéros d'instructions. Pour chaque détermination, n au dénominateur (n-1)! est décrémenté d'une unité.
Ainsi, pour le nombre aléatoire choisi 101, la position de l'emplacement du premier numéro d'instruction est 101/(5-1)!=4, comme représenté sur la Figure 3a. Le reste de 101/(5-1)! est 5 et la position de l'emplacement du deuxième numéro d'instruction est 5/(4-1)!=0, comme représenté sur la Figure 3b. Le reste de 5/(4-1)! est 5 et la position de l'emplacement du troisième numéro d'instruction est 5/(3-1)!=2, comme représenté sur la Figure 3c. Le reste de 5/(3-1)! est 1 et la position de l'emplacement du quatrième numéro d'instruction est 1/(2-1)!=1, comme représenté sur la Figure 3d. Le cinquième numéro d'instruction va occuper la position de l'emplacement restant disponible, comme illustré sur la Figure 3e.
La séquence de permutation "25431" (issue de la Figure 3e) est alors introduite dans le tableau 30 de pointeurs d'instructions permutées (de la Figure 2) en tant qu'entrée pour la 101ème séquence de permutation. Un programme d'application peut être permuté selon la 101ème séquence de permutation en un jeu de code compilé de façon croisée via le compilateur croisé 28 (de la Figure 2). Pendant l'exécution, le jeu de code compilé de façon croisée peut être exécuté via le module d'exécution 29 (de la Figure 2) selon la 101ème séquence de permutation mémorisée dans le tableau 30 de pointeurs d'instructions permutées.
Par exemple, si les cinq instructions à permuter sont ADD, SUBSTRACT, JUMP, BRANCH et STORE, alors chacune de ces instructions se voit attribuer un numéro d'instruction en conséquence, c'est-à-dire instruction numéro 1 = ADD, instruction numéro 2 = SUBSTRACT, instruction numéro 3 = JUMP, instruction numéro 4 = BRANCH et instruction numéro 5 = STORE. Lorsqu'on fera appel à la 101ème séquence de permutation pour effectuer la compilation croisée d'un programme d'application au sein du compilateur croisé 28 de la Figure 2, chaque occurrence des cinq instructions susmentionnées au sein du programme d'application sera transformée selon la séquence de permutation "25431". En d'autres termes, chaque instruction ADD au sein du programme d'application sera transformée en instruction SUBSTRACT, chaque instruction SUBSTRACT au sein du programme d'application sera transformée en instruction STORE, chaque instruction JUMP au sein du programme d'application sera transformée en instruction BRANCH, chaque instruction BRANCH au sein du programme d'application sera transformée en instruction JUMP, chaque instruction STORE au sein du programme d'application sera transformée en instruction ADD. Une inversion de la transformation susmentionnée est effectuée au sein du module d'exécution 29 de la Figure 2 pendant l'exécution du code compilé de façon croisée du programme d'application.
La permutation peut être effectuée de manière soit statique, soit dynamique. Si la permutation est effectuée de manière statique, alors un groupe de systèmes informatiques peut être réglé pour utiliser la même séquence de permutation. Une telle pratique serait plus facile pour un directeur des technologies de l'information car la compilation croisée de chaque programme d'application n'aurait à être effectuée qu'une fois pendant l'installation.
Si la permutation est effectuée de manière dynamique, il existe plusieurs choix. Un jeu de séquences de permutation peut être changé périodiquement. Une compilation croisée pour ces permutations peut être effectuée une fois puis, chaque fois qu'un système informatique s'amorce, il peut exécuter un jeu différent de programmes compilés de façon croisée, sur la base de la séquence de permutation effectivement en usage. En outre, la séquence de permutation peut changer de façon aléatoire chaque fois que le système informatique s'amorce. Dans ce cas, la compilation croisée devrait être faite "à la volée" par un compilateur croisé s'exécutant sur le système informatique.
De plus, la séquence de permutation peut également être changée pour chaque programme d'application, et cela peut être accompli par différents procédés. La mise en oeuvre la plus simple consiste à faire utiliser au VMM le hachage de signature d'une application comme clé pour un algorithme de cryptage de flux, générant ainsi un jeu d'instructions unique pour ce programme d'application. Tout programme d'application modifié (notamment modifié dans une mémoire principale du fait d'un virus qui provoque un dépassement de tampon) commencera à générer un jeu d'instructions différent.
En variante, le VMM peut générer un nombre aléatoire chaque fois qu'un programme d'application est chargé et les segments de code du programme d'application passent par un moteur de cryptage de flux ou de hachage (puisqu'il n'a pas besoin d'être réversible) pour modifier la compilation croisée. Ce procédé donne un niveau supplémentaire de sécurité en ce que la fonction Pn(A) devient une fonction constante P(A) et reste imprévisible.
Comme il a été décrit, la présente invention met à disposition un procédé destiné à empêcher l'exécution de logiciels malveillants au sein d'un système informatique. Si le VMM conserve une permutation associée au hachage de chaque application permutée qui doit être exécutée, alors même une attaque par échantillonnage (où une application permutée tenant lieu d'échantillon est obtenue d'une manière quelconque par un attaquant et la permutation déterminée est appliquée à un virus envoyé ensuite pour effectuer une infection) échoue.
Il est également important d'observer que bien que la présente invention ait été décrite dans le contexte d'un système informatique entièrement fonctionnel, l'homme de métier appréciera que les mécanismes de la présente invention sont en mesure d'être distribués comme un programme sous des formes variées et que la présente invention s'applique indifféremment quel que soit le type particulier de support de signaux utilisé pour effectuer la distribution proprement dite. Des exemples de supports de signaux comprennent, sans caractère limitatif, des supports de type enregistrable tels que des disquettes ou des disques compacts et des supports de type à transmission tels que des liaisons analogiques ou numériques de communication.
Bien que l'invention ait été représentée et décrite en référence à un mode de réalisation préféré, il sera compris par l'homme de métier que divers changements dans la forme et les détails peuvent y être apportés sans s'écarter de l'esprit et du champ de l'invention.