Réécriture de programmes pour une application effective
des politiques de sécurité
Thèse présentée
à la Faculté des études supérieures de l’Université Laval dans le cadre du programme de doctorat en informatique pour l’obtention du grade de Philosophiæ doctor (Ph.d.)
FACULTÉ DES SCIENCES ET DE GÉNIE UNIVERSITÉ LAVAL
QUÉBEC
2011
c
Durant ces dernières décennies, nous avons assisté à une automatisation massive de la société selon toutes ses sphères. Malheureusement, cette révolution technologique n’a pas eu que des bienfaits. En effet, une nouvelle génération de criminels en a profité, afin d’occasion-ner davantage d’activités illégales. De ce fait, afin de protéger les systèmes informatiques, il est devenu plus que primordial de définir rigoureusement des politiques de sécurité ainsi que de mettre en œuvre des mécanismes efficaces capables de les appliquer. L’objectif majeur d’un mécanisme de sécurité consiste souvent à contrôler des logiciels, afin de les contraindre à “bien” se comporter. Cependant, la plupart des mécanismes de sécurité procèdent par des méthodes ad hoc qui sont loin d’être efficaces. En outre, ils sont peu fiables, puisqu’il n’y a aucune preuve sur leur capacité à faire respecter les politiques de sécurité. De là apparaît la nécessité de concevoir des mécanismes de sécurité alternatifs qui résolvent le problème de l’application de la sécurité d’une manière formelle, correcte et précise. Dans ce contexte, notre thèse cible principalement la caractérisation formelle de l’application effective des po-litiques de sécurité via des mécanismes basés sur la réécriture de programmes. On entend par application effective, le fait d’éliminer tous les “mauvais” comportements d’un programme, tout en conservant tous les “bons” comportements qu’il engendre, et ce, sans compromettre la sémantique du programme à sécuriser. Nous avons opté pour la réécriture de programmes, vu sa grande puissance par rapport aux autres mécanismes de sécurité qui sont soit laxistes soit très restrictifs. Les principaux résultats qui ont été réalisés, afin d’atteindre les objectifs ciblés par cette thèse sont les suivants :
– Caractérisation formelle de l’application des propriétés de sûreté par la réécriture de programmes. Il s’agit d’appliquer les propriétés de sûreté qui constituent la classe de propriétés de sécurité la plus communément appliquée par les mécanismes de sécurité. – Caractérisation formelle de l’application de n’importe quelle propriété de sécurité par la réécriture de programmes. Cette contribution montre comment la réécriture de pro-grammes permet l’application de politiques de sécurité qu’aucune autre classe de mé-canismes de sécurité ne peut appliquer.
– Caractérisation alternative de l’application de la sécurité par une approche algé-brique. Cette contribution propose un formalisme algébrique afin de réduire l’écart entre la spécification et l’implantation des mécanismes de sécurité basés-réécriture.
During the last decades, we have witnessed a massive automation of the society at all levels. Unfortunately, this technological revolution came with its burden of disadvantages. Indeed, a new generation of criminals emerged and is benefitting from continuous progress of information technologies to cause more illegal activities. Thus, to protect computer systems, it has become very crucial to rigorously define security policies and provide the effective me-chanisms required to enforce them. Usually, the main objective of a security mechanism is to control the executions of a software and ensure that it will never violate the enforced security policy. However, the majority of security mechanisms are based on ad hoc methods and thus, are not effective. In addition, they are unreliable, since there is no evidence on their ability to enforce security policies. Therefore, there is a need to develop novel security mechanisms that allow enforcing security policies in a formal, correct, and accurate way. In this context, our thesis targets the formal characterization of effective security policies enforcement that is based on programs rewriting. We mean by “effective” enforcement preventing all the “bad” behaviors of a program while keeping all its "good" behaviors. In addition, effective enfor-cement should not compromise the semantics of controlled programs. We have chosen for rewriting programs, because it has a great power compared to other security mechanisms that are either permissive or too restrictive. The main contributions of this thesis are the following : – Formal characterization of security enforcement of safety properties through program rewriting. Safety properties represent the main class of properties usually enforced by security mechanisms.
– Formal characterization of any security property using program rewriting. This contri-bution shows how program rewriting allows the enforcement of security policies that no other class of security mechanisms can enforce.
– Algebraic approach as an alternative formal characterization of program rewriting based security enforcement. In this contribution, we investigate an algebraic formal model in order to reduce the gap between the specification and the implementation of program rewriting based security mechansisms.
Je tiens avant tout à exprimer ma profonde reconnaissance au professeur Mohamed Me-jri, qui a assuré la direction de cette thèse. Ses conseils judicieux, son esprit critique et sa curiosité intellectuelle m’ont toujours inspirée et motivée pour mener les travaux de cette recherche. Qu’il trouve ici l’expression de mon plus profond respect. J’adresse également mes vifs remerciements à mon codirecteur professeur Kamel Adi, pour son enthousiasme scientifique, pour ses directives perspicaces ainsi que pour ses encouragements.
J’exprime ma gratitude au : Dr. Hanifa Boucheneb, Dr. Nadia Tawbi et Dr. Béchi Ktari pour avoir accepté d’être membres de mon jury et pour l’honneur qu’ils me font en évaluant mes travaux.
Je remercie également Mme Lynda Goulet pour sa gentillesse et pour sa disponibilité. Je tiens à remercier affectueusement ma tendre mère, pour tous les sacrifices qu’elle a faits et qu’elle continue de faire pour nous offrir la meilleure éducation qui soit. Je remercie également les membres de ma grande famille, mes soeurs : Lynda, Djouher, Karima, Mounia et Safia ainsi que mes frères : Karim et Hakim et mes beaux frères : Smail, Ouahab et Sofiane, pour leur soutien indéfectible. Je remercie égalements mes beaux parents pour leurs multiples encouragements.
J’aimerai également remercier ma seconde famille : Ratiba Sebhi, Mona Hussein et Omar Seddiki. Je leur suis très reconnaissante pour avoir rendu ma vie agréable au Canada.
Je remercie par la même occasion, mon adorable petite fille Rym dont je suis très fière ainsi que mon petit bébé Aymane qui m’a inspirée durant la rédaction de cette thèse. Enfin, je remercie mon époux Chamseddine, pour son soutien inconditionnel, ses perpétuels encou-ragements et particulièrement pour le souffle d’optimisme avec lequel il a su me propulser pour que je puisse donner le meilleur de moi-même.
À la mémoire de mon père, Ismaïl Ould-Slimane.
Résumé ii
Abstract iii
Table des matières ix
Liste des tableaux x
Table des figures xii
1 Introduction 1 1.1 Enjeux . . . 1 1.2 Problématique et motivations . . . 1 1.3 Objectifs . . . 3 1.4 Contributions . . . 4 1.5 Organisation du document . . . 6
I
Application de la sécurité : Notions de base et état de l’art
7
2 Généralités sur la sécurité informatique 8 2.1 Introduction . . . 82.2 Attaques . . . 9
2.2.1 Virus . . . 9
2.2.2 Vers . . . 10
2.2.3 Chevaux de Troie . . . 11
2.2.4 Bombes logiques et temporelles . . . 12
2.2.5 Trappes . . . 12
2.2.6 Canaux cachés . . . 13
2.3 Vulnérabilités des logiciels . . . 14
2.3.1 Débordement des zones mémoire . . . 14
2.3.2 Failles d’injection de codes malicieux . . . 15
2.4 Politiques de sécurité . . . 18 2.4.1 Authentification . . . 19 2.4.2 Non-répudiation . . . 19 2.4.3 Disponibilité . . . 20 2.4.4 Autorisation . . . 20 2.4.5 Intégrité . . . 20 2.5 Modèles de sécurité . . . 21 2.5.1 Modèle de Bell-LaPadula . . . 21 2.5.2 Modèle Biba . . . 23
2.5.3 Modèle de Brewer-Nash ou Muraille de Chine . . . 24
2.6 Mécanismes de sécurité . . . 26
2.6.1 Monitorage d’exécution . . . 27
2.6.2 Réécriture de programmes . . . 28
2.6.3 Analyse statique . . . 28
2.7 Conclusion . . . 32
3 Caractérisation de l’application de la sécurité 34 3.1 Introduction . . . 34
3.2 Objectifs de la caractérisation formelle . . . 35
3.3 Application des politiques de sécurité . . . 35
3.3.1 Politiques de sécurité . . . 35
3.3.2 Propriétés de sécurité . . . 36
3.3.3 Mécanismes de sécurité . . . 37
3.3.4 Monitorage d’exécution vs réécriture de programmes . . . 38
3.4 Automates de sécurité . . . 39
3.4.1 Présentation . . . 39
3.4.2 Contraintes de calculabilité . . . 42
3.4.3 Intégration du moniteur d’exécution dans un programme . . . 42
3.5 Automates d’édition . . . 45
3.5.1 Présentation . . . 45
3.5.2 Niveaux d’application . . . 47
3.5.3 Langage Polymer . . . 53
3.6 Automates à historique superficiel . . . 54
3.7 Spécification orientée optimisation . . . 56
3.8 Caractérisation selon la théorie de la calculabilité . . . 58
3.8.1 Présentation . . . 58
3.8.2 Mobile . . . 61
3.9 Synthèse . . . 63
3.9.1 Contributions théoriques . . . 63
3.9.2 Considération des contraintes pratiques . . . 64
II
Caractérisation des mécanismes de sécurité basés réécriture
67
4 Application des propriétés de sûreté 68
4.1 Introduction . . . 68
4.2 Modèle formel et principe de la composition . . . 69
4.2.1 Opérateur de composition d’automates⊙ . . . 71
4.2.2 Composition d’automates appliquée aux mécanismes de sécurité . . . 72
4.3 Théorèmes . . . 77
4.4 Exemples . . . 79
4.4.1 Troncation de traces . . . 79
4.4.2 Test dynamique . . . 82
4.5 Conclusion . . . 84
5 Application des propriétés spécifiables par les automates d’édition 86 5.1 Introduction . . . 86
5.2 Problématique de la simulation des actions . . . 87
5.2.1 Violation de la transparence . . . 88
5.2.2 Violation de la correction . . . 90
5.2.3 Nos contributions . . . 90
5.3 Cadre formel . . . 92
5.3.1 Machines à états finis étendues MEFEs . . . 92
5.3.2 Automates d’édition . . . 93
5.3.3 Démarche . . . 94
5.4 Opérateur de composition . . . 95
5.4.1 H : La fonction calculant l’historique des actions simulées . . . 97
5.4.2 R : La fonction calculant les transitions . . . 98
5.4.3 Optimisation . . . 104 5.5 Principaux résultats . . . 104 5.5.1 Définitions . . . 105 5.5.2 Correction . . . 107 5.5.3 Transparence . . . 112 5.6 Exemple . . . 114 5.7 Conclusion . . . 117
6 Application des propriétés de sécurité par approche algébrique 118 6.1 Introduction . . . 118
6.2 Application des propriétés de sûreté . . . 119
6.2.1 Langage de spécification : BPA∗0,1 . . . 119
6.2.2 Description formelle de l’approche . . . 124
6.2.3 Résolution du problème . . . 126
6.2.5 Exemple . . . 137
6.3 Application des propriétés spécifiables par les automates d’édition . . . 138
6.3.1 Langage de spécification : EBPA∗0,1 . . . 139
6.3.2 Processus pgfc dans EBPA∗0,1 . . . 144
6.3.3 Calcul deP ⊓λ τ Q . . . 151
6.3.4 Algorithme . . . 153
6.3.5 Exemples . . . 154
6.4 Manipulation des actions conditionnées . . . 157
6.4.1 Terminologie . . . 157
6.4.2 Langage de spécifications CEBPA∗0,1 . . . 158
6.4.3 Calcul deP ⊓λ τ Q . . . . 160 6.4.4 Exemple . . . 164 6.5 Conclusion . . . 167 7 Conclusion 169 Bibliographie 172
3.1 Règles sémantiques d’un automate d’édition. . . 48
5.1 FonctionH calculant l’historique . . . 97
5.2 FonctionR calculant les attributs des transitions de EP,φ . . . 98
5.3 Fonction de satisfaction . . . 101
5.4 Test dynamique. . . 102
5.5 Fonction d’éditionΩ . . . 104
6.1 Sémantique opérationnelle du langage BPA∗0,1. . . 121
6.2 Définition de la fonctiono dans BPA∗0,1 . . . 122
6.3 Oùα ∈ {a, a−, a+} . . . . 127
6.4 Algorithme calculantP ⊓ Q dans BPA∗0,1 . . . 136
6.5 Sémantique opérationnelle de EBPA∗0,1. . . 140
6.6 Définition de la fonctiono dans EBPA∗0,1 . . . 142
6.7 Exécution du processusa.b−.c+ dans EBPA∗ 0,1. . . 142
6.8 Algorithme calculantP ⊓ Q dans EBPA∗0,1 . . . 153
6.9 Syntaxe de CEBPA∗0,1. . . 159
6.10 Sémantique opérationnelle de CEBPA∗0,1. . . 159
2.1 Vulnérabilité de dépassement de capacité d’un tableau dans un programmeC. 14
2.2 Propriétés de base appliquées par le modèle Bell-LaPadula : NRU & NWD. . 21
2.3 Propriétés de base appliquées par le modèle Biba : NRD & NWU. . . 22
2.4 Propriété “Subject low watermark” appliquée par le modèle Biba. . . 23
2.5 Propriété “Object low watermark” appliquée par le modèle Biba. . . 24
2.6 Situation de flot indirect. Les objets o1 et o2 appartiennent aux compagnies C1 et C2 respectivement. C1 et C2 sont en conflit d’intérêts. . . 25
2.7 Trois principales classes de mécanismes de sécurité. . . 26
2.8 Approche générale de l’application de la sécurité en se basant sur la certifi-cation de programmes. . . 32
3.1 Trois principales classes de mécanismes de sécurité. . . 38
3.2 Politique : “Pas d’envoi après la lecture d’un fichier”. . . 41
3.3 Propriétés applicables précisément. . . 49
3.4 Propriétés effectivement applicables. . . 51
3.5 Propriétés régénératrices - applicables effectivement modulo la relation “=”. . 52
3.6 Application de la sécurité selon Polymer. . . 53
3.7 Machine de turing modélisant l’analyse statique. . . 60
3.8 Machine de turing modélisant un moniteur d’exécution. . . 60
3.9 Taxonomie des politiques de sécurité applicable selon Hamlen et al. [51]. . . 62
4.1 Exemple 1. L’AEFAφ1 spécifiant la propriétéφ1 . . . 79
4.2 ProgrammeP g - Version A : avant application de φ1. Version B : après ap-plication deφ1 - . . . 80
4.3 Exemple 1. L’AEFAP gcorrespondant au programmeP g. . . . 80
4.4 Exemple 1. L’AEF résultant de la composition deAφ1 etAP gavant optimisation. 81 4.5 Exemple 1. L’AEF de la figure4.4après optimisation. . . 82
4.6 Exemple 2. L’AEF spécifiant la propriétéφ2. . . 82
4.7 AEF résultant de la composition deAφ2 etAP gavant optimisation. . . 83
4.8 Exemple 2. Automate simplifié du programme respectant la propriétéφ2 . . . 83
4.9 ProgrammeP g - Version A : avant application de φ2. Version C : après ap-plication deφ2 - . . . 84
5.1 Programme P - Version A - . . . 88
5.2 Programme P - Version B - . . . 88
5.3 Programme P’ - Version A - . . . 89
5.4 Programme P’ - Version B - . . . 91
5.5 MEFEEφ1 spécifiant l’automate d’édition spécifiant la propriétéφ1. . . 94
5.6 MEFE spécifiant l’automate d’édition appliquant la propriétéφ2. . . 115
5.7 MEFE EP1 . . . 116
5.8 MEFE résultant de la composition deEP1 etEφ2 . . . 116
6.1 Exemple : Calcul dupgfc correspondant à deux processusP et Q où P re-présente un programme etQ une propriété. . . . 154
6.2 Exemple de deux processusR et S et de leurpgfccorrespondant. . . 156
6.3 Automate de sécurité spécifiant la propriétéΦ. . . 165
Introduction
1.1
Enjeux
Durant la dernière décennie, nous avons assisté à l’essor phénoménal d’Internet, une gi-gantesque toile qui a engendré une connectivité massive. Ainsi, nous avons observé une très grande accessibilité des logiciels, principalement attribuée à l’adoption de l’approche “Open source”. Par conséquent, la consommation de ces logiciels s’est vue étendre à très grande échelle, particulièrement les logiciels provenant de sources douteuses. De ce fait, les utilisa-teurs sont de plus en plus tentés d’exécuter sur leurs machines une panoplie de programmes qui sont loin d’être inoffensifs. En effet, la consommation démesurée de ces produits a la-bouré de vastes champs fertiles, devant les semeurs de troubles informatiques. Ces derniers n’ont qu’un seul objectif : innover et exceller dans la création de codes malicieux, afin de cau-ser le maximum de dégâts possibles. Ces codes malicieux peuvent être des bombes logiques, des virus, des vers, des chevaux de Troie, des logiciels espions et la liste est loin d’être fi-nie. C’est pour faire face à toutes ces menaces qu’est née la sécurité informatique. L’objectif majeur de cette discipline est de protéger les utilisateurs de produits informatiques, en par-ticulier les logiciels, des risques qu’engendrent ces codes malicieux sur leurs vies privées, professionnelles ainsi que sur leurs biens.
1.2
Problématique et motivations
Dans ce contexte, la question imminente qui se pose est la suivante : comment se proté-ger des codes malicieux ? Il est évident qu’afin de combattre et affronter son ennemi, il est
primordial de pouvoir l’identifier. Par conséquent, il faudra définir avec précision ce qu’on entend par comportement malicieux. Cela a engendré le besoin crucial d’établir un diag-nostic sur le comportement des programmes. D’une manière plus précise, ce diagdiag-nostic doit permettre sans ambiguïté la distinction entre les comportements acceptables et les comporte-ments inacceptables des programmes. En réalité, cette distinction constitue ce qu’on appelle une politique de sécurité. En effet, une politique de sécurité est définie telle que tout compor-tement acceptable la satisfait et tout comporcompor-tement inacceptable la viole. Il est à noter qu’un comportement acceptable par rapport à une certaine politique de sécurité peut être considéré comme étant inacceptable par rapport à une autre politique. Par conséquent, la définition des politiques de sécurité constitue la notion clé qui est souvent adoptée, afin de contraindre un code potentiellement malicieux à “bien” se comporter.
La définition minutieuse des politiques de sécurité représente une tâche primordiale, pour la sécurité de n’importe quelle plateforme informatique. Néanmoins, en l’absence de mesures concrètes et efficaces pour l’application et la mise en œuvre de ces politiques, ces dernières ne resteront que des “souhaits” de conception sécurisée. Cette mise en œuvre constitue ce qu’on appelle “mécanismes de sécurité”. Ces mécanismes englobent tout produit, logiciel ou matériel, permettant d’appliquer et d’imposer des politiques de sécurité aux programmes s’exécutant sous son contrôle. Plus précisément, ces mécanismes garantissent l’interdiction de l’exécution de comportements jugés inacceptables par les politiques de sécurité à instau-rer. Par ailleurs, on dit qu’un mécanisme applique effectivement une politique de sécurité, s’il autorise l’exécution de tout comportement satisfaisant la politique de sécurité et si, en revanche, il exclut l’exécution de tout comportement qui viole la politique en question.
Parmi les mécanismes de sécurité les plus omniprésents, on retrouve les moniteurs d’exé-cution. En effet, les moniteurs d’exécution constituent une classe de mécanismes qui a dé-montré sa puissance et son efficacité dans plusieurs domaines. Afin d’appliquer une propriété de sécurité sur un programme, le moniteur d’exécution intercepte d’abord les événements critiques en termes de sécurité, ensuite il exécute une procédure d’intervention pertinente à l’action interceptée, et ce, à chaque fois que celle-ci tente de violer les exigences dictées par la propriété de sécurité à appliquer [96]. Cependant, l’efficacité des moniteurs d’exécutions entraîne des surcoûts significatifs en termes de temps machine et d’espace mémoire. Ces surcoûts sont essentiellement dus aux manipulations logicielles et/ou matérielles nécessaires pour : la capture des événements critiques à la sécurité, l’analyse de l’historique d’exécution du programme (la trace) et enfin la mise en œuvre de la procédure d’intervention. À vrai dire, des surcoûts considérables peuvent être évités si la structure interne du programme à contrôler est accessible au moniteur. En effet, le fait d’analyser statiquement le programme peut révéler qu’un grand nombre d’invocations critiques à la sécurité se trouve être totale-ment inoffensif et donc peut être ignoré durant le contrôle, en toute sécurité. Aussi, l’analyse de l’historique d’exécution peut être simplifiée et réduite en considérant uniquement l’étape
courante du programme.
Tous ces facteurs ont favorisé l’avènement de l’approche de réécriture de programmes qui s’est imposée comme étant l’alternative idéale aux moniteurs d’exécution [37,51]. Dans cette approche, une propriété de sécurité est appliquée au sein d’un programme en le réécri-vant de sorte à produire une version équivalente, mais plus restrictive, qui satisfait la propriété en question. Dans [51], la réécriture de programme est identifiée comme étant une technique extrêmement avantageuse qui peut être utilisée pour appliquer des propriétés qu’un moniteur d’exécution échouerait à appliquer. Généralement, les techniques de réécriture consistent à prendre un moniteur d’exécution, souvent spécifié par un automate de sécurité [96] et l’em-barquer dans le corps du programme à contrôler [37,38].
Une étude critique de l’état de l’art nous a permis de constater que la majorité des méca-nismes de sécurité procèdent d’une manière ad hoc. En effet, il y a peu de travaux formels menés dans le sens d’une application efficace et précise des politiques de sécurité. Pour la plupart des mécanismes rencontrés en pratique, nous ne disposons pas de preuves formelles démontrant que ces mécanismes appliquent réellement les politiques qu’ils prétendent assu-rer. Aussi, il y a peu de travaux sur la délimitation des classes de politiques applicables par les mécanismes mis en œuvre. Par conséquent, il serait intéressant de proposer une nouvelle vi-sion, sur la manière d’appliquer les politiques de sécurité. Cette nouvelle vision doit répondre précisément aux questions du genre : que signifie un “bon” mécanisme de sécurité ? Quelles sont les limites d’un mécanisme de sécurité ? Ainsi, nous éviterons de voir faillir des mé-canismes de sécurité dans l’application des politiques de sécurité qui leur sont acheminées. Dans ce contexte, cette thèse se joint aux efforts de quelques chercheurs [42,51,73,96,113] qui se sont penchés sur des problématiques liées à la caractérisation formelle des mécanismes de sécurité et des politiques de sécurité qu’ils peuvent appliquer.
1.3
Objectifs
L’objectif principal de cette thèse consiste en la caractérisation formelle de l’application de la sécurité par la réécriture de programmes. En effet, les contributions antérieures de la communauté scientifique ont démontré le grand potentiel des mécanismes de sécurité basés réécriture, dans l’application des politiques de sécurité. Plus précisément, l’état de l’art a longuement fait la promotion de la réécriture de programmes comme étant une excellente al-ternative au monitorage d’exécution. Effectivement, l’atout majeur de la réécriture est le fait qu’elle permet d’appliquer plus de politiques de sécurité que les autres mécanismes, tout en garantissant une réduction considérable des surcoûts engendrés par leur application. Néan-moins, bien que cette approche soit incontestablement capable d’assurer la plus grande classe
de politiques de sécurité, les études connexes menées à ce jour se sont uniquement limitées aux politiques applicables par les moniteurs d’exécution. Par conséquent, ces travaux ont faussement présagé que l’unique apport de la réécriture de programmes se limite uniquement à l’efficacité de l’application des politiques de sécurité, par rapport aux ressources consom-mées. Dans ce contexte, les objectifs spécifiques de notre thèse sont les suivants :
– Étudier les classes de politiques de sécurité applicables par la réécriture de pro-grammes. Cette étude doit permettre une meilleure compréhension des classes de poli-tiques de sécurité qu’on peut appliquer par cette classe de mécanismes de sécurité (la réécriture). De plus, une attention particulière est accordée à une meilleure délimita-tion entre (1) les politiques de sécurité que la réécriture de programmes peut appliquer comme alternative au monitorage d’exécution et (2) celles dont la réécriture de pro-grammes se démarque par leur application par rapport au monitorage d’exécution. – Caractériser formellement l’application de la sécurité basée réécriture de programmes.
Cette activité de recherche vise à spécifier les fondements théoriques caractérisant le processus d’application des classes de politiques de sécurité. Il s’agit principalement de cibler les politiques de sécurité identifiées comme résultat de l’étape précédente. Dans cette première caractérisation, une attention particulière est accordée aux politiques de sécurité que seule la réécriture de programmes est capable d’appliquer.
– Investiguer des fondements théoriques alternatifs pour la caractérisation de l’applica-tion de la sécurité via réécriture de programmes. Il existe diverses manières de modéli-ser le comportement d’un programme. Par conséquent, il modéli-serait intéressant de mettre en œuvre ces modèles, afin de proposer des caractérisations formelles alternatives de l’ap-plication de la sécurité, dans le contexte précis de la réécriture de programmes. En effet, cette diversité de modèles permet d’évaluer et de cerner plusieurs facettes liées au pro-blème de caractérisation formelle de la sécurité. De ce fait, nous visons la proposition d’un deuxième formalisme, afin d’appliquer la sécurité et de compléter éventuellement les résultats apportés par la première caractérisation (ciblée par l’objectif précédent) par rapport à l’aspect automatisation du mécanisme de sécurité.
1.4
Contributions
Les principales contributions de cette thèse sont les suivantes :
– Caractérisation formelle de l’application des propriétés de sûreté par la réécriture de programmes [87,88]. Dans cette contribution, nous nous sommes particulièrement
in-téressés à l’application effective d’une propriété de sûreté au sein d’un programme. Cette tâche est effectuée, en réécrivant les programmes pour en produire de nouvelles versions fiables (fiabilité du point de vue de la propriété à appliquer). L’application effective de la sécurité se base sur deux conditions principales : la correction et de la transparence. La correction s’assure que la nouvelle version du programme satisfait la politique de sûreté, sans pour autant introduire des comportements (exécutions) non supportés par la version originale du programme. La transparence, quant à elle, ex-prime le fait que la nouvelle version du programme doit absolument inclure tous les comportements valides (satisfaisant la propriété de sûreté) qui sont censés être générés par la version originale du programme. En effet, le non-respect de ces deux conditions a affecté négativement la fiabilité des contributions antérieures recensées dans l’état de l’art ; il s’agissait souvent de méthodes d’application conservatrice de la sécurité. – Caractérisation formelle de l’application de n’importe quelle propriété de sécurité par
la réécriture de programmes [89]. Dans cette contribution, nous avons focalisé sur une plus grande classe de propriétés de sécurité. La classe que nous avons ciblée est au-delà des propriétés de sûreté, auxquelles se limite la majorité des travaux existants. Dans la littérature, les propriétés ciblées par cette contribution sont identifiées comme étant des propriétés spécifiables par des moniteurs d’exécution sophistiqués. Les fon-dements théoriques de ces “supers” moniteurs sont basés sur les automates d’édition [73]. Ces moniteurs d’exécution sont censés pouvoir suspendre l’exécution des actions des programmes contrôlés ainsi qu’y insérer (exécuter) des séquences d’actions. Dans notre contribution, nous avons démontré que ce nouveau pouvoir attribué aux moni-teurs d’exécution, qui est déjà limité à un sous-ensemble d’actions de programmes, ne peut respecter les conditions de correction et de transparence citées ci dessus. Par ailleurs, nous avons prouvé que la réécriture de programmes est mieux appropriée pour l’application des propriétés de sécurité, notamment celles qui ne sont pas des propriétés de sûreté. En effet, ce type de propriété requiert une stratégie particulière que même un automate d’édition ne saurait appliquer (à cause de l’hypothèse de la non-accessibilité du code, dans le contexte du monitorage). Plus précisément, le cadre formel que nous avons proposé pour la caractérisation de cette application repose sur les machines à états finis étendues. Ce modèle nous a permis de spécifier un opérateur de composition “intelligent” qui à partir d’une propriété de sécurité et d’un programme, génère une nouvelle version du programme qui satisfait la propriété et qui est conforme à la spéci-fication du programme d’origine. Notre formalisme nous a particulièrement permis de simuler l’effet des actions suspendues sur les variables de programmes. En effet, c’est cette simulation qui assure l’application effective de la sécurité, une précision dont un moniteur ne dispose pas.
[90]. Les deux contributions précédentes sont basées sur les systèmes de transitions ; principalement sur les machines à états finis. Ce modèle a parfaitement répondu à nos besoins, en matière de caractérisation formelle de l’application de la sécurité. Cepen-dant, afin d’explorer des alternatives d’implémentation et d’automatisation de l’opéra-teur de composition proposé précédemment, nous avons dû étudier d’autres modèles formels. Le modèle le plus pertinent à notre recherche consistait à développer un calcul algébrique. Afin d’adapter le contexte algébrique à nos besoins, nous y avons subtile-ment intégré les primitives d’acceptation, de suspension et d’insertion d’actions. Aussi, afin de pouvoir simuler des actions et les réinsérer dans le futur, nous avons dû incor-porer la notion d’historique à la sémantique de l’algèbre de processus que nous avons proposée. Par conséquent, grâce à la grande expressivité et au caractère incrémental des algèbres de processus, nous avons pu spécifier tous les éléments inhérents à l’applica-tion des propriétés de sécurité (les propriétés de sûreté et les propriétés spécifiables par les automates d’édition). En outre, avec cette caractérisation formelle, le processus de composition de la propriété et du programme a été transposé vers un problème de résolution de systèmes linéaires d’équations. La solution à ce système n’est autre que le programme valide.
1.5
Organisation du document
La thèse est organisée en deux parties principales. La première partie relate la littérature relative à notre sujet recherche et comporte deux chapitres. Dans le chapitre2, nous présen-tons les notions de base relatives à la sécurité informatique en général et à la sécurité des logiciels en particulier. Dans le chapitre3, nous survolons l’état de l’art du domaine de la ca-ractérisation formelle des mécanismes de sécurité. Pour chaque contribution pertinente, nous avons décrit l’approche ainsi que les contributions théoriques et pratiques qu’elle a engen-drées.
La seconde partie décrit nos trois principales contributions. Dans le chapitre4, nous pré-sentons notre caractérisation formelle de l’application des propriétés de sûreté par la réécri-ture de programmes. Dans le chapitre 5, nous présentons une autre approche formelle qui cible cette fois-ci l’application d’une plus grande classe de politiques de sécurité, il s’agit de la classe des propriétés spécifiables par les automates d’édition. Dans, le chapitre6, nous pro-posons un formalisme algébrique comme étant une autre alternative pour la caractérisation de l’application de la sécurité, dans un contexte de réécriture de programmes.
Enfin, nous énonçons dans le chapitre7 les principales contributions de cette recherche, et nous émettons quelques perspectives pour une éventuelle suite des travaux de cette thèse.
Application de la sécurité : Notions de
base et état de l’art
Généralités sur la sécurité informatique
2.1
Introduction
Depuis l’avènement de l’automatisation de l’information, les problèmes liés à la sécurité informatique n’ont cessé de croître d’une manière spectaculaire. Par conséquent, la sécurité est devenue une science jouissant d’une grande importance sur tous les plans de notre vie moderne. En effet, le besoin crucial de sécuriser les systèmes automatisés s’impose dans plu-sieurs environnements plus au moins critiques tels que : les structures militaires, les centrales nucléaires, le monitorage d’intraveineuses, jusqu’à nos propres ordinateurs. Le moindre dys-fonctionnement affectant ces systèmes peut toujours entraîner le chaos total et des pertes fort regrettables. Afin d’éviter ce genre de scénarios dramatiques, les chercheurs de la com-munauté de la sécurité informatique ont déployé des efforts considérables, notamment pour l’identification de la multitude de dangers qui menacent les ressources informatiques, ainsi que pour la proposition et la mise œuvre de techniques efficaces pour contrer ces menaces. Dans ce chapitre, nous abordons les notions de base relatives à la sécurité informatique en général et à la sécurité des logiciels en particulier. Nous commençons par décrire les diverses attaques qui menacent les plateformes informatiques. Ensuite, nous présentons les principales vulnérabilités qui sont exploitées, afin de monter ces attaques. Finalement, nous décrivons les éléments clés de n’importe quelle solution de sécurité, à savoir : les politiques de sécurité ainsi que les mécanismes permettant leur application.
2.2
Attaques
Afin de proposer des solutions efficaces pouvant assurer la sécurité des ressources in-formatiques, il est impératif d’identifier clairement les différentes attaques qui ciblent ces ressources. Aussi, il faut comprendre exactement la manière dont procèdent ces attaquants. Plus encore, il faut trouver des stratégies pour prédire leurs actions malveillantes et leurs por-tées. Dans cette section, nous présentons les principaux ingrédients utilisés pour mener des attaques sur les ressources informatiques.
2.2.1
Virus
Un virus informatique est un code malicieux conçu pour se propager sur des ordinateurs, en s’insérant dans des programmes légitimes appelés “hôtes”. Il peut affecter plus ou moins gravement le fonctionnement de l’ordinateur qu’il a infecté. Afin de se propager, le virus peut se servir de tout moyen d’échange de données numériques tels que les réseaux informatiques, les cédéroms, les clés USB, etc.
L’origine du terme " virus informatique " est attribuée à l’informaticien et spécialiste en biologie moléculaire Leonard Adleman. En fait, le virus informatique est similaire au virus biologique dans son mode de propagation, puisqu’il exploite les capacités de multiplication des cellules hôtes. Aussi, il ne faut pas confondre les virus informatiques avec les vers infor-matiques, qui sont quant à eux des programmes capables de se propager et de se dupliquer par leurs propres moyens sans utiliser de programmes hôtes. En général, le mot virus est souvent utilisé d’une manière abusive pour désigner toute forme de codes malicieux.
Le nombre total de programmes malveillants identifiés jusqu’à présent serait de l’ordre de 95 000 selon Sophos. Cependant, le nombre de virus qui circule effectivement ne dépasserait pas quelques milliers. En effet, pour des fins de marketing, c’est les créateurs d’antivirus qui s’acharnent à “gonfler” le nombre de virus détectés par leurs produits. La majorité de ces virus concerne la plateforme Windows. Bien qu’ils soient extrêmement rares, il existe aussi des virus qui infectent les systèmes de type Unix/Linux. Néanmoins aucune épidémie comparable à celle des virus Windows n’a encore été constatée jusqu’à date.
Aussi, on assiste périodiquement à une saturation démesurée des divers systèmes de mes-sagerie. Cette saturation est principalement causée par de fausses alertes de virus. Ces der-nières se répandent le plus souvent par le biais de la rumeur. Dans la plupart des cas, ces rumeurs exploitent la naïveté des utilisateurs, qui par panique, se montrent crédules et se
soumettent au contenu de la rumeur, détruisant des zones totalement saines de leur systèmes d’exploitation.
2.2.2
Vers
Un ver informatique est un logiciel malveillant qui se reproduit sur plusieurs ordinateurs, en utilisant un réseau informatique comme Internet. Contrairement à un virus informatique, un ver n’a pas besoin d’un programme hôte pour se multiplier. Pour ce faire, il exploite les différentes ressources de l’ordinateur qui l’héberge, afin d’assurer sa duplication. L’objec-tif d’un ver n’est pas seulement de se reproduire, il possède aussi des objecL’objec-tifs malicieux comme :
– espionner les activités des utilisateurs ;
– prendre le contrôle de l’ordinateur à distance ; – offrir une porte dérobée aux pirates informatiques ;
– détruire des données de l’ordinateur où il se trouve ou y causer d’autres dommages ; – saturer les serveurs en envoyant de multiples requêtes (déni de service).
Aussi, les vers peuvent également entraîner des effets secondaires non négligeables comme : – le ralentissement de la machine infectée ;
– le ralentissement du segment du réseau contenant la machine infectée ; – le plantage du système d’exploitation de la machine infectée.
Les vers peuvent provenir directement du réseau en profitant d’un port ouvert. Plus sou-vent, la méthode la plus prisée par les vers est de s’infiltrer sous forme de pièce jointe attachée à un courriel. Croyant que ce sont des données qui lui sont destinées, l’utilisateur active le ver par la simple lecture du courriel ou par la consultation de la pièce jointe.
Les vers sont souvent développés en utilisant des langages de programmation tels que : C, C++, Delphi, assembleur, etc. Généralement, les vers utilisent des failles de logiciels pour se propager. Pour contrer ces vers, les développeurs de logiciels neutralisent ces failles, en
réécrivant le code, dès l’apparition des vers attaquant ces derniers. Par conséquent, s’assurer de détenir les versions les plus récentes des logiciels dès leur apparition sur le marché peut réduire significativement le risque d’infection par des vers informatiques.
2.2.3
Chevaux de Troie
Un cheval de Troie se présente comme étant une application utile et légitime, mais qui est en réalité un programme nuisible principalement conçu pour mener furtivement des actions malveillantes au sein de la machine sur laquelle il est installé.
Un cheval de Troie est avant tout un programme client-serveur. Généralement, l’objectif majeur d’un cheval de Troie consiste à scruter les informations de la machine qu’il infecte, en exploitant les données qu’il a captées, notamment les droits d’accès à des zones protégées. Un cheval de Troie se permet de détourner, de diffuser ou de détruire des informations. Il peut aussi ouvrir des portes dérobées qui permettent aux attaquants de prendre le contrôle de la machine à distance. Les principales sources qui diffusent les chevaux de Troie sont : Windows Live Messenger, le téléchargement d’applications gratuites ainsi que le partage de photos ou d’autres fichiers multimédia. Les chevaux de Troie sont également très fréquents dans certains types de courriels.
Contrairement aux virus ou aux vers, les chevaux de Troie ne se reproduisent pas par eux-mêmes. Il se trouve que les chevaux de Troie offrent généralement des fonctionnalités très attrayantes, c’est donc à cause de leurs téléchargements ou le fait qu’ils soient échangés ou copiés entre utilisateurs, qu’ils assurent leur survie et ainsi leur reproduction. En fait, un cheval de Troie est composé de deux parties distinctes : la partie “client” et la partie “serveur”. La partie client est la partie acheminée à la victime tandis que la partie serveur reste toujours sur l’ordinateur du pirate. La partie client est envoyée par courriel et se présente souvent comme étant une version améliorée d’un logiciel tel que : MSN, Adobe Photoshop, etc. Il peut aussi se dissimuler sous une apparence plus captivante telle qu’un test de QI ou comme un jeu à caractère lucratif. Le cheval de Troie se glisse donc dans l’ordinateur et s’installe dans la base de registres. Le fichier peut également s’infiltrer et s’installer dans l’autoexec de démarrage, afin d’être opérationnel dès le lancement de la machine. À ce moment, il ouvre une porte dérobée, sur le port de l’ordinateur choisi par le pirate et établit une connexion avec l’ordinateur pirate. La partie serveur, quant à elle, s’occupe d’acheminer les instructions à la partie client qui réside dans l’ordinateur de la victime. Le pirate peut alors prendre le contrôle absolu de l’ordinateur de la victime. À titre d’exemple, il peut commander la souris ou le clavier, imprimer, initialiser le disque dur, etc. D’une manière générale, on peut répartir les chevaux de Troie en deux catégories :
– À connexion directe : Dans cette catégorie, c’est le pirate qui se connecte à la victime. Ce type de chevaux de Troie est de moins en moins utilisé, puisque le pirate a besoin de l’adresse IP de sa victime pour pouvoir agir ;
– À connection distante : Dans cette catégorie, c’est l’ordinateur victime qui se connecte au pirate. À chaque fois que la victime est connectée, le pirate est averti de cette connexion grâce à une liste qu’il détient et qui comporte les états de toutes ses victimes potentielles. De cette manière, les chevaux de Troie peuvent être transmis à grande échelle.
2.2.4
Bombes logiques et temporelles
Une bombe logique est un bout de code malveillant inséré dans un logiciel qui contient des fonctions destinées à causer des dommages dans l’ordinateur infecté. Cette bombe ne s’active que si un événement précis a lieu, d’où l’appellation “bombe logique”. La bombe temporelle quant à elle, constitue un cas particulier des bombes logiques avec comme condi-tion de déclenchement une date et une heure précise. Comme exemple, on entend souvent parler de bombes créées par un employer furieux qu’il déclenchera furtivement dans le sys-tème informatique de l’entreprise où il travaille, si jamais il est licencié, ou s’il n’est pas suffisamment rémunéré pour ses tâches.
2.2.5
Trappes
Une porte dérobée (de l’anglais backdoor, littéralement porte de derrière) appelée aussi trappe est une fonctionnalité inconnue de l’utilisateur légitime, qui donne un accès secret à sa machine. La présence d’une porte dérobée dans un logiciel à l’insu de son utilisateur transforme ce logiciel en un cheval de Troie. La personne qui connaît ce passage secret peut l’exploiter pour surveiller les activités du logiciel, voire en prendre le contrôle (par contour-nement de l’authentification). Enfin, selon l’étendue des droits que le système d’exploitation donne au logiciel contenant la porte dérobée, le contrôle peut s’étendre à l’ensemble des opérations de l’ordinateur.
Vu la grande connectivité des ordinateurs modernes, notamment via les réseaux intranet et internet, le fait de disposer de trappes est devenu un moyen très pratique pour le contrôle des machines situées sur des sites très éloignés. Un tel contrôle permet aux fournisseurs de logiciels un accès privilégié à leurs produits afin d’y accomplir efficacement des actions de maintenance à tout moment. Aussi, ils auront la possibilité de désactiver furtivement un
produit logiciel, en cas de conflit avec le client (par exemple le non-paiement de licence). Parmi les motivations amenant les pirates informatiques à installer une porte dérobée, on retrouve :
– la possibilité d’espionner les activités de l’utilisateur légitime de l’ordinateur et de co-pier ou détruire des données confidentielles (mots de passe, coordonnées bancaires, secrets commerciaux, etc.) ;
– la possibilité de prendre le contrôle d’un ordinateur et de pouvoir le commander pour mener des actions malicieuses (envoi de pourriels notamment pour l’hameçonnage de virus informatiques, déni de service, etc.) ;
– le contrôle d’un vaste réseau d’ordinateurs appelés “zombies”, afin de l’utiliser pour occasionner un chantage au déni de service distribué (DDoS), ou de le revendre à des criminels.
2.2.6
Canaux cachés
Un canal caché est un canal de communication qui utilise la bande passante d’un autre canal dans l’objectif de transmettre des informations sans l’autorisation ou la connaissance du propriétaire de l’information ou de l’administrateur du réseau. Les canaux cachés sont des entités dynamiques ; ils s’approprient un espace mémoire sans nécessairement en avoir besoin. Si pour un utilisateur normal, les antivirus et autres pare-feux sont souvent suffisants pour contrecarrer une attaque par un cheval de Troie, ils sont totalement impuissants devant un canal caché bruité. Principalement, il existe deux types de canaux cachés :
– Les canaux de stockage : le processus émetteur modifie une donnée particulière, et le processus récepteur détecte et interprète la donnée modifiée pour recevoir indirecte-ment des informations.
– Les canaux de minutage : le processus émetteur module la durée d’une tâche effectuée par le processus récepteur, et le processus récepteur interprète cette variation comme une information.
void copieNaive (char *input) {
char buffer[16];
strcpy (buffer, input); ...
}
int main (int argc, char *argv[]) {
...
copieNaive (argv[1]); ...
}
FIGURE 2.1 – Vulnérabilité de dépassement de capacité d’un tableau dans un programmeC.
2.3
Vulnérabilités des logiciels
Dans cette section, nous présentons les principales vulnérabilités qui sont souvent exploi-tées afin de monter des attaques contre les systèmes informatiques.
2.3.1
Débordement des zones mémoire
Les variables manipulées par les logiciels sont généralement stockées dans des zones mémoire. La taille de la zone mémoire allouée à chaque variable est souvent définie par le programmeur en fonction de son estimation de la nature et de la quantité d’information que la variable pourra contenir durant le cycle de vie du logiciel. La vérification ou non de la taille d’une donnée, avant sa sauvegarde dans une variable, est souvent laissée au bon jugement des programmeurs. Ces derniers décident souvent de vérifier la taille de la donnée s’ils sup-posent qu’elle est aléatoire ou de ne pas la vérifier s’ils croient qu’elle ne dépassera jamais la taille de la variable ou tout simplement s’ils sont insoucieux du problème. Cependant, si une variable se voit attribuer une quantité d’information supérieure à sa capacité, ceci peut engen-drer des conséquences graves sur le logiciel. En effet, dans de telles situations, l’information copiée dans la variable déborde sur les zones mémoire adjacentes. Les conséquences de ce débordement varient entre l’écrasement des données stockées auparavant (perte ou destruc-tion de données) à l’injecdestruc-tion de code malicieux qui sera utilisé plus tard par un programme malveillant pour prendre le contrôle du système.
Les formes les plus populaires du débordement des zones mémoire sont les dépassements de capacité d’entiers et de tableaux. Ces vulnérabilités sont souvent le résultat de l’adop-tion de languages de programmal’adop-tion puissants tels queC/C++,C♯et ceux faisant appel aux librairies basées sur ces languages tel que Java. La figure2.1montre un cas typique de vul-nérabilité de dépassement de capacité d’un tableau. Dans le code de cette figure, la fonction
copieNaivecopie la chaîne de caractères reçue en entrée (paramètreinput) dans le
ta-bleau de caractères bufferde taille fixe. La copie est réalisée par la fonction C standard
strcpyqui n’effectue aucune vérification sur les tailles des variables qu’elle manipule. En
effet, la fonctionstrcpyest l’une des fonctions C qui sont des plus vulnérables aux débor-dements des zones mémoire. Bien que des versions plus sécuritaires de ces fonctions ont été proposées, les versions vulnérables demeurent populaires.
2.3.2
Failles d’injection de codes malicieux
Les logiciels interagissent souvent avec les utilisateurs humains ou autres logiciels via la communication de données. Les données reçues en entrée par un logiciel sont analysées et acheminées vers des composants logiciels pour traitement. Dépendamment de la nature de l’analyse effectuée sur les entrées avant leur le traitement, ces dernières peuvent causer l’exécution de codes malicieux. Ce type de vulnérabilités est appelé “injection” puisqu’elles injectent du code malicieux qui sera exécuté par le logiciel vulnérable. Il existe différents types d’injections, les plus importants sont l’injection SQL, l’injection de commandes et l’in-jection de scripts à distance ou “Cross-site scripting”. Par souci de brièveté, seule l’inl’in-jection SQL sera expliquée via un exemple dans cette section.
Une injection SQL est une attaque exploitant une vulnérabilité d’un logiciel interagissant avec une base de données. L’attaque est basée sur l’envoi de données qui causeront l’exécu-tion d’une requête SQL autre que celle prévue par le logiciel. La requête exécutée est choisie afin de compromettre la sécurité de la base de données en accédant par exemple à des données confidentielles. Afin de comprendre comment une injection SQL peut être effectuée, nous présentons l’exemple d’une requête SQL utilisée par un site web dynamique (programmé en PHP) pour permettre aux utilisateurs de se connecter en fournissant un nom d’utilisateur et un mot de passe valides. La requête SQL suivante permet ce genre de connexion :
SELECT uid WHERE
name = ‘(Nom)’ AND
password = ‘(MotDePasse)’;
données en entrée, un pirate peut monter une attaque d’injection SQL afin de se connecter en tant que “Alice” ; un utilisateur légitime du site web. Les informations envoyées en entrée par le pirate sont les suivantes :
– Utilisateur : Alice’ -– Mot de passe : peu importe
La requête exécutée par le script en réponse à ces entrées est la suivante :
SELECT uid WHERE
name = ‘Alice’ -- ’ AND password = ‘peu importe’;
Comme les caractères “- -” marquent le début d’un commentaire en SQL, la requête est alors équivalente à :
SELECT uid WHERE name = ‘Alice’;
L’exécution de cette requête permet au pirate de se connecter au site web sous l’identité “Alice” ou n’importe quel utilisateur légitime, à condition de connaître le nom de l’utilisa-teur (name) sans avoir à fournir de mot de passe. Il s’agit d’une injection SQL puisque le pirate a réussi à injecter les données permettant de changer le comportement d’une requête du logiciel, afin d’effectuer des accès non autorisés.
L’injection de commandes est basée sur le même principe de l’injection SQL ; fournir des données afin de provoquer un traitement autre que celui prévu par le logiciel. Cepen-dant, l’injection des commandes est effectuée sur des shell de systèmes d’exploitation. Ces attaques sont possibles lorsque les données manipulées par les commandes système ne sont pas analysées avant l’exécution de ces dernières.
Le cross-site scripting (XSS) est une vulnérabilité de sécurité des sites Web. L’attaquant peut exploiter ces vulnérabilités afin de provoquer un comportement d’un site web qui n’a pas été prévu par son concepteur. Le comportement malicieux est souvent provoqué via l’in-jection de données arbitraires qui peuvent être un message dans un forum, des paramètres d’URL, etc. L’attaque se concrétise si les données injectées seront transmises aux naviga-teurs (via paramètres d’URL, un message posté, etc.) sans vérification au préalable. Comme résultat, le navigateur web exécutera du code malveillant en langage de script (le plus sou-vent en JavaScript). Les principaux risques liés à l’exploitation des vulnérabilités XSS sont les suivants :
– Redirection de l’utilisateur ;
– Vol d’informations (telles que : les sessions, les cookies, etc.) ;
– Actions, à l’insu de la victime et en son nom, sur le site vulnérable (exemple : envoi de messages, suppression de données, etc.) ;
– Déni de service sur une page web (exemple : exécution de boucles infinies).
2.3.3
Absence ou faible protection de données critiques
Les données critiques manipulées par un logiciel doivent être protégées. Cette protection couvre l’accès à ces données, leur mise à jour, leur transfert sur les réseaux de communica-tion, etc. La confidentialité des données critiques peut être compromise lors de la présence des vulnérabilités suivantes :
– Données non protégées. Si les données critiques sont sauvegardées dans des zones mémoire ne bénéficiant pas de mesure de protection telle que le cryptage, le contrôle d’accès, etc.
– Trafics non protégés. Si les données critiques sont transférées via les canaux de commu-nication sans être chiffrées, communiquées à des entités non authentifiées au préalable. – Mauvaises utilisations des mots de passe. Les mots de passe jouent un rôle très impor-tant dans n’importe quel mécanisme de protection de données critiques. Cependant, un mot de passe peut être le maillon faible à cause des vulnérabilités suivantes :
◦ Génération de mots de passe faciles à détecter ;
◦ Choix de mots de passe trop simples ou facilement déductibles à partir des informa-tions personnelles des usagers telles que : nom et prénom, adresse, date de naissance, etc ;
◦ Longue durée de vie d’un mot de passe. Les usagers sont souvent paresseux lorsqu’il est question de changement périodique de leurs mots de passe ;
– Générateurs pseudoaléatoires faibles. Les nombres pseudoaléatoires sont très impor-tants dans n’importe quel mécanisme de cryptage ou protocole cryptographique. La protection des données est compromise si ces nombres peuvent être prédits à cause d’une faiblesse dans les algorithmes adoptés pour leur génération. La faiblesse la plus commune est l’utilisation de la valeur de l’horloge système comme paramètre princi-pal dans la génération des nombres pseudoaléatoires. Un attaquant connaissant l’algo-rithme utilisé peut deviner le nombre généré, et par conséquent la clé utilisée dans le cryptage. Ceci peut être réalisé en essayant plusieurs valeurs à l’intérieur de l’intervalle de temps durant lequel le nombre a été généré.
2.4
Politiques de sécurité
Afin de protéger les systèmes informatiques contre toutes les formes de danger qui les menacent, des politiques de sécurité devraient être rigoureusement définies et imposées à tout programme s’exécutant dans le système. Une politique de sécurité définit des contraintes sur l’exécution des programmes. En d’autres termes, la politique de sécurité se doit de décrire tout comportement indésirable pouvant nuire à la sécurité du programme. Les politiques de sécurité visent généralement les principaux objectifs suivants :
– Intégrité : garantir que les données sont bien celles que l’on croit être ;
– Confidentialité : assurer que seules les parties autorisées aient accès aux données échan-gées ;
– Disponibilité : maintenir le bon fonctionnement du système information informatique en assurant la disponibilité des ressources et des services pour les différentes entités interagissant avec le système ;
– Non-répudiation : garantir qu’une transaction ne peut être niée par une partie y partici-pant ;
– Authentification : vérifier qu’une personne possède bien l’identité ou les droits qu’elle prétend avoir ;
– Autorisation : vérifier qu’une personne n’accède qu’aux ressources dont elle a déjà obtenu l’autorisation d’accès de la part de l’entité qui gère la sécurité du système.
Dans ce qui suit, nous allons aborder plus en détail les politiques de sécurité qui visent à atteindre ces objectifs.
2.4.1
Authentification
L’authentification consiste à vérifier qu’une personne possède bien l’identité ou les droits qu’elle affirme avoir. L’authentification repose sur les trois critères suivants :
– Ce qu’une personne sait (un mot de passe, etc.) ;
– Ce qu’une personne possède (une carte à puce, une clé de stockage, un certificat, etc.) ; – Ce qu’une personne est, c’est-à-dire une caractéristique physique de cette personne, on
parle alors de biométrie (le fond de rétine, les empreintes digitales, l’ADN, etc.). Lorsque le processus d’authentification requiert une seule preuve d’identité, par exemple le mot de passe, on parle d’authentification simple. Quand le processus d’authentification requiert plus d’un critère, alors on parle de “forte authentification”.
2.4.2
Non-répudiation
La non-répudiation est une politique importante dans le monde des affaires. Elle prévient la remise en cause d’un contrat ou d’une entente par une des parties impliquées. Vu la très grande migration vers le commerce électronique, cette classe de politiques de sécurité est d’une importance majeure. En effet, dans les transactions commerciales effectuées via inter-net, il est souvent le cas que les parties impliquées ne peuvent pas se rencontrer face à face pour signer un contrat.
Afin d’exprimer cette politique dans le contexte d’un système informatique, la non-répud-iation s’applique en vérifiant que l’expéditeur et le destinataire d’un message sont bien ceux qui prétendent avoir respectivement envoyé et reçu le message. Par conséquent, la non-répudiation d’un message peut être effectuée en deux phases : la non-non-répudiation de l’origine et la non-répudiation de la destination. La première prouve qu’un message a été envoyé par l’expéditeur alors que la deuxième prouve que le message a bien été reçu par le destinataire.
L’application de la non-répudiation repose sur l’authentification des expéditeurs et des destinataires. Cette authentification est souvent effectuée en utilisant les certificats
numé-riques. Les certificats sont créés et attribués par une entité appelée autorité de certification. Un individu est authentifié auprès d’une autorité qui lui attribuera une clé privée avec laquelle il doit signer ses messages et un certificat qui prouve le lien entre le nom de l’individu et la clé privée. Comme la clé privée n’est connue que par l’individu pour lequel elle a été créée, la réception d’un message signé par cette clé représente une preuve de l’identité de celui qui l’a utilisé et par conséquent une preuve de sa participation à la transaction impliquant le message signé.
2.4.3
Disponibilité
Les politiques de sécurité qui sont relatives à l’objectif de disponibilité décrivent le fait qu’il est interdit de monopoliser l’utilisation d’une ressource par un programme. En d’autres termes, cette politique spécifie le fait que toute ressource réquisitionnée devrait être libérée ultérieurement durant l’exécution. Une autre façon de spécifier une politique de disponibilité est d’exprimer le fait d’imposer une borne supérieure sur l’intervalle de temps séparant l’ac-quisition d’une ressource et sa libération. Cette borne supérieure peut être spécifiée en termes d’unités d’exécution (par exemple les instructions) ou d’unités de temps.
2.4.4
Autorisation
Les politiques de sécurité relatives à l’objectif de l’autorisation doivent spécifier avec pré-cision les droits d’accès que possède chaque entité du système sur les différentes ressources protégées. L’application de n’importe quelle politique d’autorisation repose sur l’authentifi-cation des entités. En effet, si une entité A arrive à se faire passer pour une autre entité B
alors elle (l’entitéA) peut bénéficier des privilèges de l’entité B et par conséquent violer la
politique d’autorisation en vigueur.
2.4.5
Intégrité
L’intégrité des données est une propriété très importante dans n’importe quelle communi-cation via les réseaux de télécommunicommuni-cations. En effet, plusieurs attaques sont basées sur l’al-tération du contenu des messages échangés entre deux parties distantes. Une politique d’in-tégrité permet de détecter toute manipulation frauduleuse du contenu d’un message. L’appli-cation de cette politique repose souvent sur une fonction de hachage calculant une empreinte d’une donnée critique envoyée dans un message. En recevant le message, la même fonction
de hachage est appliquée sur la donnée critique reçue. Le résultat est alors comparé à la va-leur de hachage reçue. Toute différence détectée est interprétée comme une altération de la donnée critique pendant son transfert entre l’expéditeur et le récepteur.
2.5
Modèles de sécurité
Une spécification précise d’une politique de sécurité et le déploiement d’un mécanisme effectif pour son application dépendent énormément de la modélisation adoptée des res-sources systèmes et des entités les manipulant. Dans cette section, nous présentons les mo-dèles de sécurité classiques décrits dans l’état de l’art. Il est à noter qu’un modèle de sécurité implémente les fondements abstraits sur lesquels repose la politique de sécurité ciblée. Ceci inclut une définition précise des structures de données à utiliser ainsi que les algorithmes les manipulant.
FIGURE 2.2 – Propriétés de base appliquées par le modèle Bell-LaPadula : NRU & NWD.
2.5.1
Modèle de Bell-LaPadula
Le modèle de Bell-LaPadula [14] a été développé au début des années 70 par D. Elliot Bell et Leonard LaPadula. Le modèle a été développé dans le cadre d’un projet d’un système d’exploitation sécurisé en temps partagé pour les applications militaires “Multics”. L’objectif principal du modèle est de s’assurer de la confidentialité des informations. Dans ce modèle, à chaque sujet est associé un niveau d’habilitation : ultra-secret, secret, publique, etc. De la
même façon, les objets (ressources à protéger) sont classés selon leur niveau de confiden-tialité : ultra-secret, secret, publique, etc. L’objectif de ce modèle est de prévenir qu’un sujet obtient de l’information d’une classe supérieure. Les propriétés de sécurité de base appliquées par le modèle Bell-LaPadula sont les suivantes (Figure2.2) :
– NRU (No Read Up) : Aucun sujet n’a le droit de lire une information à partir d’un objet appartenant à un niveau de sécurité supérieur ;
– NWD (No Write Down) : Aucun sujet n’a le droit d’écrire une information dans un objet appartenant à un niveau de sécurité inférieur.
Des propriétés plus complexes peuvent être également supportées par ce modèle, on peut citer :
– Propriété discrétionnaire : Un sujet n’a le droit d’exécuter que les actions permises par une matrice d’accès M donnée. Les lignes de la matrice M sont des sujets et les
colonnes sont des objet. La case de la matrice correspondante à un sujetA et un objet o contient la liste des actions que A peut entreprendre sur o, telles que : lire, écrire,
exécuter, etc.
FIGURE 2.3 – Propriétés de base appliquées par le modèle Biba : NRD & NWU.
– Tranquillité faible (Weak tranquility) : Après sa création, un sujet ou un objet ne peut changer sont niveau de confidentialité que si ce changement respecte une certaine po-litique de sécurité. Par exemple :
FIGURE 2.4 – Propriété “Subject low watermark” appliquée par le modèle Biba. sujet.
◦ Un sujet ne peut pas changer son niveau de confidentialité lorsqu’il est entrain d’uti-liser un objet.
– Tranquillité forte (Strong tranquility) : Après sa création, un sujet ou un objet ne peut plus changer sont niveau de confidentialité.
2.5.2
Modèle Biba
Le modèle Biba [65] a été développé au milieu des années 70 par Ken Biba. L’objec-tif principal du modèle est de s’assurer de l’intégrité des informations. Tout comme Bell-LaPadula, le modèle Biba se base sur l’attribution de niveaux de confidentialité aux sujets et aux objets. L’objectif de ce modèle est de prévenir qu’un sujet contamine l’information de sa classe ou d’une classe supérieure. Les propriétés de sécurité de base appliquées par le modèle Biba sont les suivantes (Figure2.3) :
– NRD (No Read Down) : Aucun sujet n’a le droit de lire une information à partir d’un objet appartenant à un niveau de sécurité inférieur ;
FIGURE 2.5 – Propriété “Object low watermark” appliquée par le modèle Biba.
appartenant à un niveau de sécurité supérieur.
Afin de permettre aux sujets et aux objets de changer de niveaux de sécurité, deux va-riantes du modèle de Biba ont été proposées. Concernant les sujets, on trouve le modèle “Subject low watermark” et pour les objets, on trouve le modèle “Object low watermark”. La propriété appliquée par le modèle “Subject low watermark” (Figure2.4) permet à un sujet de lire une information à partir d’un objet de niveau de sécurité inférieur. Cependant, une fois ce genre de lecture est effectuée par un sujetA sur un objet o, le niveau de sécurité de A sera
baissé à celui deo. D’une façon similaire, la propriété appliquée par le modèle “Object low
watermark” (Figure2.5) permet à un sujet d’écrire une information dans un objet de niveau de sécurité supérieur. Cependant, une fois ce genre d’écriture est effectuée par un sujetA sur
un objeto, le niveau de sécurité de o sera baissé à celui de A.
2.5.3
Modèle de Brewer-Nash ou Muraille de Chine
Le modèle de Brewer-Nash ou Muraille de Chine a été développé en 1987 par David Brewer et Michael Nash [26]. L’objectif principal du modèle est de spécifier les contrôles d’accès, afin d’éviter tout conflit d’intérêts. Ce modèle est très utile dans le contexte des affaires. En effet, afin d’assurer une compétition honnête entre les différentes compagnies œuvrant dans le même secteur d’affaires, il est primordial d’empêcher toute fuite d’informa-tion entre les concurrents. En considérant les sujets et les objets, un conflit d’intérêts survient lorsqu’un sujet a accès aux informations confidentielles (objets) de deux compagnies en
com-FIGURE2.6 – Situation de flot indirect. Les objets o1 et o2 appartiennent aux compagnies C1 et C2 respectivement. C1 et C2 sont en conflit d’intérêts.
pétition. Dans ce genre de situation, un flot d’information est identifié d’une compagnie vers une autre. Afin d’empêcher le genre de flot d’information décrit ci-haut, la propriété suivante a été proposée :
“L’accès en lecture à un objeto, d’une compagnie C, par un sujet A sera refusé si A a pu
lire dans le passé un objeto′d’une compagnieC′compétitrice deC”.
Cependant, cette propriété n’est pas suffisante. En effet, des situations de flot indirect d’information peuvent survenir sans pour autant violer la propriété. Prenant le cas des trois objetso1, o2 et o3 appartenant respectivement aux compagnies C1 et C2 et C3 (Figure2.6. Les compagniesC1 et C2 sont en conflit d’intérêt alors que C3n’est en conflit d’intérêt avec
aucune des deux autres compagnies. Regardons le scénario suivant : (1) un sujet A lit de
l’information deo1 puis écrit dans o3, (2) le sujet B lit de l’information de o3 puis écrit dans o2. Aucune étape de ce scénario ne viole la propriété malgré le flot d’information indirect de o1 vers o2 en passant par o3. Afin de remédier à ce genre de situation, la propriété précédente
est renforcée par la propriété suivante :
“L’accès en écriture à un objeto, d’une compagnie C, par un sujet A sera refusé si A a pu
