Généralités sur les interruptions

Une interruption est un événement particulier qui peuvent se produire lors de l’exécution d’un programme. A chaque type d’interruption est associé un numéro appelé vecteur d’interruption, connu du ou des processeur(s). Pour simplifier, les interruptions peuvent provenir de deux sources : le logiciel et le matériel. Les interruptions matérielles sont générées par les périphériques (clavier, souris, cartes, timers, disques durs…) et sont transmises au processeur par l’APIC (Advanced Programmable Interrupt Controller).  Les interruptions logicielles peuvent être quant à elles déclenchées volontairement par une instruction (int) ou de façon accidentelle par une erreur arithmétique, logique, de protection, etc. Dans ce cas, on parle souvent d’exception et de fautes.

Généralement, les interruptions (aussi bien matérielles que logicielles) sont susceptibles de se déclencher à n’importe quel moment dans l’exécution d’un programme, et chaque processeur doit savoir comment traiter chacune d’entre elles. A chaque vecteur d’interruption on associe alors un handler d’interruption, qui est une fonction qui sera appelée automatiquement quand l’interruption sera générée.  On place ces fonctions dans une table, l’IDT, pour Interrupt Descriptor Table. Il est important de noter qu’il y a une IDT par processeur, afin que chacun puisse avoir si besoin un comportement différent pour chaque interruption.

Il existe deux types d’interruptions matérielles, les masquables (les IRQ) et les non masquables (la NMI et la SMI) qu’on ne traitera pas ici en raison de leur grande particularité. Chaque interruption matérielle possède une priorité, qui est gérée par l’APIC. Pour faire simple, ce composant est relié aux périphériques par des lignes d’IRQ (Interrupt Requests) et se charge de faire le médiateur entre tous ces périphériques et le ou les processeur(s). Son rôle est en gros de transformer ces IRQ en demandes d’interruptions avec le vecteur associé.  Comme plusieurs IRQ peuvent intervenir en même temps, l’APIC définit des priorités afin de transmettre les plus urgentes d’abord.

Dans certains cas, le processeur peut ne pas vouloir être dérangé par une interruption. C’est le cas par exemple lorsqu’il est en train de modifier des structures globales en mémoire. Il a alors la possibilité d’ignorer les interruptions qu’il va recevoir de deux manières. La première, que je ne détaillerai pas, est de ne masquer que celles dont la priorité est inférieure à un certain seuil (appelé IRQL sous Windows) en communiquant avec l’APIC. La deuxième est de masquer la totalité des interruptions et c’est celle que nous allons détailler.

Subtilité sur le masquage

C’est le registre EFLAGS et plus précisément son bit IF (bit 9) qui contrôle si les interruptions masquables sont activées ou non. Ce bit est modifiable par l’intermédiaire des instructions cli pour masquage et sti pour démasquage, ou bien en utilisant pushf / popf associés à des masques.

Attention, le masquage des interruptions n’affecte que les interruptions matérielles ! Les interruptions logicielles (ainsi que les interruptions NMI et SMI, très particulières) ne sont pas affectées par ces opérations. Autrement dit, vous aurez beau baisser l’IRQL ou faire un cli, une exception due à une division par zéro ou à un défaut de page pourra toujours survenir.

Problème n°1 : DbgPrint(), c’est le mal

J’ai fait tous mes tests en machine virtuelle. Comme le développement de driver n’est jamais sûr à 100% et que je voulais tout de même avoir quelque chose de fonctionnel, j’ai réalisé un petit script qui charge le driver et le décharge 100 fois de suite, en lançant en plus des programmes divers pour solliciter l’OS un maximum. Le tout étant de prouver que le driver n’explose pas à la première interruption, bien entendu.

Dans mon cas, je devais hooker l’interruption n°14 correspondant au défaut de page (page fault), en insérant du code avant de rappeler le handler par défaut de Windows. Je rappelle que cette exception (logicielle) se produit quand une page virtuelle n’est mappée à aucune adresse physique (soit parce qu’elle a été swappée sur disque, soit parce qu’elle n’existe tout simplement pas). Cela se produit quand on tente d’accéder à une page dont le descripteur PTE a son premier bit (bit P) à 0.

J’ai donc commencé par concevoir un handler minimal qui ne faisait rien à part empiler tous les registres, les dépiler puis appeler le handler de Windows, KiTrap0E. Jusqu’ici, tout fonctionne, sauf que je n’ai pas vraiment de preuve que ma routine est appelée (vu que je n’ai aucune trace).

Je me décide donc à insérer des DbgPrint() dans le code de la routine. Et là, c’est le drame : j’obtiens des traces certes, mais j’en obtiens tellement que la VM freeze ou affiche un écran bleu au bout de quelques secondes. Il faut croire que les défauts de page sont très nombreux sous Windows… Mais pourquoi ça plante maintenant et pas avant ? L’explication est liée au visualisateur de traces (j’utilise DebugView). Lorsque DbgPrint() est appelé, le message est récupéré par le noyau puis par DebugView. Je ne sais pas exactement pourquoi, mais apparemment quand il y a beaucoup de messages de récupérés, DebugView commence à provoquer des défauts de page (probablement à cause du fait qu’il se fait swapper par l’OS). Comme ces défauts de pages sont à leur tour catchés par mon handler, ils entraînent d’autres appels à DbgPrint()… Bref, une belle boucle qui finit par exploser tôt ou tard.

Au final, je renonce donc  à afficher des traces, vu que cela perturbe plus le système qu’autre chose. En plus j’ai ma preuve que mon handler est appelé, vu que ça plante

Problème n°2 : sti, c’est aussi le mal

Le réel but de mon handler est de modifier une structure assez cruciale du noyau sous certaines conditions. Afin d’éviter que cette modification entraîne des problèmes de concurrence, je décide de masquer les interruptions avant le traitement (cli), et de les démasquer ensuite à l’aide de  et sti. Je lance le driver. Pas de crash. Je commence à crier victoire, et au moment ou je lance mon script de déchargement, j’ai le droit à un écran bleu. Je regarde le code de déchargement, il ne fait absolument rien de méchant. Je relance, idem. Je finis par comprendre que ce n’est pas le déchargement du driver qui foire, mais juste le fait de lancer un programme, car cela provoque un défaut de page… C’est donc bien mon handler qui pose problème, mais où ?

Je supprime ma modification de variable globale, ça plante toujours. Pourtant je n’ai plus que cli et sti dans mon handler (en plus de l’appel au handler par défaut). Je retire sti et je constate que ça marche ! C’est donc cette instruction qui est responsable du plantage du driver… mais pourquoi ? En fait, il se trouve que lors des appels au handler de défaut de page, les interruptions sont déjà masquées. C’est dû au fait que l’interruption correspondant au défaut de page possède un descripteur dans l’IDT qui précise que l’IF doit être mis à 0 lors de l’appel du handler (c’est une interrupt gate, selon Intel). Ainsi, lors de l’appel au handler, l’instruction cli ne fait absolument rien (le bit IF d’EFLAGS est déjà à 0)… Le problème, c’est que sti le passe à 1, ce qui autorise les interuptions ! Si jamais le défaut de page s’est produit dans une zone critique de l’OS et qu’une interruption survient précisément à ce moment, le kernel se vautre. Cela ne se produit peut-être pas à tous les coups, mais croyez moi, ça arrive (faites le test pour vous en convaincre).

Comment patcher cela ? Ne pas masquer les interruptions dans un handler de défaut de page, puisqu’elles le sont déjà. La solution, c’est tout simplement de ne rien faire

Conclusion

Morale de l’histoire : utiliser DbgPrint() ou sti dans un handler de défaut de page est une mauvaise idée. Pour déboguer, préférez utiliser des variables globales plutôt que des fonctions à effet de bords incontrôlables. Et ne cherchez pas à masquer (et surtout à démasquer) les interruptions qui le sont déjà . J’espère que ce post vous aura épargné un long moment de galère. En tout cas, j’aurais aimé en lire un du même type plus tôt !

[EDIT]

Le projet a subit de nombreux changements depuis la publication de ce billet. J’ai publié la première version du projet ici ; en attendant un tutorial vous pouvez retrouver des informations plus à jour dans ce billet. Gardez à l’esprit que les informations qui suivent (et particulièrement le jargon associé à l’outil ainsi que les fonctionnalités) ne sont plus complétement valides…

Le projet

XeeK, pour XSS Easy Exploitation Kernel, est un projet dont l’objectif est le suivant : démontrer la puissance de la XSS en proposant un outil pour exploiter facilement ce type de faille. Les premières idées qui ont engendré ce projet me sont venues cet été, mais c’est uniquement depuis quelques semaines que j’ai vraiment commencé à y travailler.

Un noyau et des modules

Certains me trouveront peut-être un peu ambitieux, mais mon but serait de faire de XeeK une sorte de Metasploit pour la XSS. Pour dire les choses autrement, l’objectif serait de proposer un framework, c’est à dire un ensemble de classes, ou de modules capables d’interagir ensemble. En fait, si le K de XeeK signifie kernel (noyau) c’est parce qu’il sera effectivement composé d’un noyau proposant les fonctionnalités génériques de base et d’une suite de modules qui pourront s’y greffer. Dans l’idéal, ces modules pourront être développés par n’importe qui. A titre de comparaison, considérez le noyau Linux et ses modules, ou bien Firefox et ses extensions.

Architecture

Concrètement, XeeK se composera d’une interface Web déployée sur un serveur appartenant à un attaquant, disons hacker.com. XeeK étant censé faciliter l’exploitation des failles XSS, il appartient à l’attaquant de découvrir ces failles ; je n’envisage pour le moment pas d’intégrer un scanner de ce type dans l’outil. Une fois une XSS trouvée sur un site quelconque, disons victime.com, l’attaquant pourra utiliser l’interface de XeeK afin de générer un exploit personnalisé et paramétrable. Après avoir défini l’exploit, celui-ci pourra être intégré à un lien piégé exploitant la XSS sur victime.com. Il ne restera plus à l’attaquant qu’à faire cliquer la victime sur ce lien…

Dans le jargon XeeK, l’attaquant commencera par créer une session, choisira sa ou ses victimes, et sélectionnera un scheduler, ou ordonnanceur. C’est ce composant qui déterminera comment les actions de l’exploit seront exécutées sur le navigateur de la victime. J’envisage pour le moment deux types de schedulers :

• Statique — toutes les actions de l’exploit seront définies à l’avance et intégrées « en dur » de façon définitive.
• Dynamique — l’exploit chargé sur le navigateur de la victime ne contiendra pas les actions proprement dit, mais un loader qui sera chargé de récupérer les actions sur le serveur XeeK (hacker.com) de façon dynamique et transparente. Ainsi, l’attaquant pourra modifier l’exploit et suivre la progression de la victime en temps réel.

Les actions exécutées chez les victimes seront susceptibles de retourner des résultats qui seront visualisables directement par le biais de l’interface. En fait, XeeK cachera l’aspect technique de l’exploitation et sera conçu pour simplifier au maximum les choses à l’attaquant. Plus précisément, l’attaquant aura devant lui une interface ressemblant à un debugger, à partir de laquelle il lance son exploit, observe sa progression et visualise les résultats. La différence avec un vrai debugger est que cet exploit sera exécuté sur les victimes et non sur sa propre machine…

Une application : BotNet

Puisque XeeK supportera plusieurs sessions en simultanée, chacune supportant elle-même plusieurs victimes, on en arrive à une des applications potentielles de l’outil : faire office de BotNet. Pour ceux qui l’ignorent, un botnet est un réseau de machines zombies contrôlable par un attaquant via un protocole quelconque. Ici, il s’agira de simples requêtes HTTP. La différence avec les « vrais » botnets est qu’ici, le code malveillant s’exécutera uniquement lorsque la victime aura son navigateur d’ouvert sur la page piégée.

Pour aider à la propagation du botnet, la possibilité la plus simple est d’utiliser une XSS permanente, c’est à dire quand l’injection de code est enregistrée en dur sur le site et affecte tous les visiteurs. Ainsi chaque visiteur tombant sur la page piégée rejoindra automatiquement le botnet à son insu et exécutera le même exploit que ses collègues. Tout cela grâce à une malheureuse petite XSS…

Imaginez qu’un site très connu et utilisé par des milliers de visiteurs soit vulnérable à une XSS permanente. Avec XeeK, il devient possible de lancer une attaque de masse contre tous les visiteurs de la page.

Fonctionnalités

Qu’est-ce que XeeK saura faire ? A vrai dire, les fonctionnalités définitives ne sont pas encore décidées (vu que les modules seront extensibles), mais voici un aperçu de ce que j’envisage.

• Furtivité du point de vue du visiteur (le site exploité continue à fonctionner sans problèmes).
• Exécution de code JavaScript arbitraire.
• Envoi de requêtes asynchrones (Ajax) vers le site vulnérable. Une des applications pourraît être d’exploiter des éventuelles failles XSRF (Cross Site Request Forgery).
• Envoi de requêtes asynchrones vers d’autres sites.
• Détournement de formulaire. Exemple : lorsque la victime remplit un des formulaires de la page, tout son contenu est envoyé sur hacker.com de façon transparente.
• Récupération de cookies.
• Récupération du contenu de la page (code HTML vu par la victime).
• Plus généralement, récupération de n’importe quelle variable accessible par JavaScript et DOM.
• Traceur de visiteur. L’exécution de l’exploit continue même si le visiteur change de page, chaque nouvelle page visitée étant loguée et accessible directement par l’attaquant.
• Simulation de clic sur des liens / boutons / n’importe quel élément graphique des pages.
• Fonctionne aussi bien en HTTPS qu’en HTTP ; cela ne change absolument rien.

Technologies

XeeK est pour le moment développé à l’aide de PHP, JavaScript, Ajax et MySQL. Bien entendu, les langages liés tels que CSS et HTML sont également utilisés à foison. Pour ce qui est de la compatibilité des navigateurs, pour être sincère je n’ai encore utilisé que Firefox. Soyons honnête ; je ne suis ni designer ni un pros des subtilités de chaque navigateur. Mais je tiens à préciser qu’avant d’effectuer une release, je ferais mon possible pour au moins que la partie « victime » de l’outil fonctionne sur IE qui est toujours, il faut le rappeler, le navigateur le plus utilisé. Je vise au moins IE7, peut-être IE6 mais il ne faut peut-être pas trop en demander pour une 1ère release

Release

Je sens venir la question « Quand XeeK sera-t-il publié ?« . Je n’ai malheureusement pas encore de réponse pour le moment. XeeK est encore au stade de prototype même si plusieurs fonctionnalités marchent déjà bien. Il me reste à concevoir la partie interface de l’outil, améliorer deux/trois petites choses, tester la partie exploitation sous IE… Comme vous pouvez vous en douter je ne travaille pas sur ce projet à plein temps, j’ai aussi des études. Pour donner une estimation, j’espère pouvoir publier une première release avant 2009. Mais cela ne constitue pas une garantie… En effet, je préfère prendre mon temps pour bien faire les choses, plutôt que de sortir quelque chose de bancal le plus vite possible. Au pire, je sortirais une alpha ou béta avant sa vraie sortie.

XeeK sera publié sous license GPL (2 ou 3). En d’autres termes, n’importe qui pourra utiliser, développer et améliorer l’outil à condition qu’il publie ses travaux également sous GPL.

Click and hack

Certains me reprocheront peut-être :

Tu n’as pas honte, de mettre à disposition des scripts kiddies un outil aussi dangereux, où il suffit de cliquer pour pirater ?

Je leur répondrai tout simplement non pour plusieurs raisons :

• Il existe des outils similaires encore lus puissants et plus simples à utiliser. Exemple : Metasploit. Personne ne se plaint de cet outil (enfin pas à ma connaissance) alors qu’il permet de rooter une machine sans aucune connaissance technique. C’est un outil utilisé par des professionnel pour le penetration testing.
• Cet outil n’est pas plus « dangereux » que les possibilités offertes par la faille XSS. Il essaye juste d’utiliser ces possibilités au maximum.
• En sortant cet outil et en le faisant connaître, j’espère faire prendre conscience à plus d’un que les failles XSS sont vraiment dangereuses, ce qui semble ne vraiment pas encore être le cas.

Sur ce, je crois que j’ai tout dit… Je vais continuer le développement de ce projet en espérant ne pas mettre trop de temps à le publier. Si vous avez des questions ou suggestions, les commentaires sont là pour ça !

#!/bin/bash

LOG_STDIN=/path/du/log/stdin.log
LOG_STDOUT=/path/du/log/stdout.log
PROG="/path/du/prog avec parametres eventuels"

tee $LOG_STDIN | $PROG | tee $LOG_STDOUT

Comme vous pouvez le voir, ce script repose sur la commande tee qui permet de dupliquer un flux.Il suffit de lancer ce script à la place du programme que vous souhaitez espionner. Cette astuce pourra être utile aussi bien au développeur qu’au reverse-engineer…

Pour la petite histoire, j’ai développé ce petit script dans le cadre d’un projet d’intelligence artificielle. Le but est de réaliser un joueur artificiel de Jeu de Go. Notre équipe a choisis d’utiliser le protocole GTP qui permet de faire communiquer des joueurs avec des interfaces graphiques. Ce script nous permet donc de déboguer plus facilement notre joueur car il permet de garder une trace des trames GTP échangées. Nous l’avons également utiliser pour avoir une idée des commandes GTP échangées entre une interface comme qGo et un joueur déjà existant tel que GNUGo.

Pour concevoir une application parallèle, on utilise assez souvent la programmation par messages. Dans le cadre de notre projet, nous utilisons la bibliothèque LAM/MPI qui fournit toute une API permettant d’envoyer des messages à des processus tournant sur des machines distantes. De plus, le but étant d’injecter des fautes, nous avons choisit de provoquer ces fautes lors des envois et réceptions de messages. Ainsi nous pouvons facilement simuler aussi bien les pannes logicielles (déni de service) et matérielles (coupure de lien d’un réseau, paquet perdu ou corrompu). Pour détourner les fonctions fournies par la bibliothèque LAM/MPI, nous utilisons la variable d’environnement LD_PRELOAD. Cette variable des systèmes UNIX/Linux permet de charger dynamiquement une bibliothèque au lancement d’une application. Le point intéressant est que cette bibliothèque peut redéfinir des fonctions qui existent déjà dans les autres bibliothèques, donc peut potentiellement les appeler tout en modifiant leur comportement.

LD_PRELOAD permet alors de modifier le comportement d’une application tout en n’ayant pas besoin de la recompiler ! Il est toutefois important de préciser que cette technique ne permet de détourner (hooker) que les fonctions définies dans des librairies dynamiques. C’est un point crucial et qui nous a posé quelques problèmes. En effet nous utilisions au départ la librairie MPICH 1, et il se trouve que lorsqu’une application est compilée avec, les appels MPI sont liés de manière statique. Un simple appel à la commande ldd permet de le voir. C’est pourquoi nous avons choisis d’utiliser LAM/MPI à la place.

Ainsi, nous avons développé une bibliothèque dynamique (fichier .so) dont le but est de venir d’interposer entre l’application parallèle et LAM/MPI. Cette bibliothèque (que nous avons nommé bibliothèque d’interposition) redéfinit les fonctions MPI_Send() et MPI_Recv() en injectant des fautes comme des corruptions de données et des dénis de service. Les fautes ne sont pas générées de manière permanentes ; nous utilisons en plus un processus qui tourne en tâche de fond (démon) qui communique avec la librairie par l’intermédiaire d’un segment de mémoire partagé. Ce démon est en réalité un serveur utilisant CORBA. Son rôle est de rester en attente de requêtes et de dialoguer avec la librairie pour déclencher l’injection de fautes. Il surveille également l’application ainsi que le système par l’intermédiaire de sondes logicielles afin de suivre en temps réel les valeurs de quelques variables, comme la charge CPU, l’occupation mémoire, etc. Ces valeurs sont sauvegardées dans une base de données pour être retraitées plus tard par un module de statistiques.

Sur chaque machine tournent donc : une instance de l’application distribuée, une instance de la bibliothèque d’interposition, et une instance du démon. Mais en plus de tout cela, il faut être capable de déployer l’application parallèle. Nous avons donc conçu un module dédié à cela, le simulateur. Il est contrôlable en ligne de commande ou via une interface graphique. Son but est de lancer l’application parallèle, les démons et activer le détournement de fonction en exportant la variable LD_PRELOAD sur toutes les machines.

Ce projet, bien que relativement complexe, se révèle très intéressant. Cela nous a permis de découvrir et d’utiliser des libraires et des technologies très utiles, comme CORBA, MPI, Boost, MySQL++. Nous utilisons également Flex et Bison pour la conception de l’interpréteur de commandes du simulateur.

Au fut et à mesure du développement, je mettrai sans doute en ligne quelques billets exposant de façon plus détaillée la conception de certains des modules.

Mise en évidence de la faille

Supposons que nous disposons d’un serveur Apache local et que nous avons une page index.php très simple comme ceci :

<h1>Bonjour !</h1>

Pour accéder à la page, nous accédons à l’URL http://127.0.0.1/~trance/vuln/ avec un navigateur Web. La requête envoyée est grossièrement la suivante :

GET http://127.0.0.1/~trance/vuln/ HTTP/1.1
Host: 127.0.0.1

La réponse reçue comporte alors le code HTML de la page Web. Jusqu’ici, tout est normal : Apache n’a fait qu’interpréter la requête GET qu’on lui a envoyé. Maintenant, imaginez que nous envoyons une requête mal formée qui n’est pas de type GET, comme :

n1Mp0rTeKwa http://127.0.0.1/~trance/vuln/ HTTP/1.1
Host: 127.0.0.1

Et là, nous constatons qu’Apache ne fait absolument aucune différence entre cette et la requête précédente ! Il n’y a aucune erreur ; il renvoie la même chose. A première vue, cela ne choque pas forcément, mais on s’aperçoit assez vite que l’on peut tirer profit de cette faille pour contourner certaines protections .htaccess.

Contourner le « Limit GET POST »

Dans de nombreux cas, un webmaster peut souhaiter restreindre l’accès à un fichier ou à un dossier sur son site Web. Pour cela, il place des fichiers .htaccess. Ces fichiers modifient localement la configuration d’Apache et utilisent une certaine syntaxe qui permet de faire des choses assez puissantes. La description de cette syntaxe est connue, et beaucoup de sites Web l’illustrent. Certains proposent une solution simple pour protéger l’accès à un fichier par un mot de passe. Il suffit, selon eux, de créer un .htaccess selon ce modèle :

<Files fichierAProteger.php>

AuthUserFile /chemin/vers/.htpasswd
AuthName "Zone à accès restreint"
AuthType Basic
    <Limit GET POST>
    require valid-user
    </Limit>
</Files>

Ce fichier permet d’indiquer à Apache de refuser toute requête POST ou GET si l’utilisateur n’est pas identifié avec un login et un mot de passe apparaissant dans le fichier .htpasswd correspondant. En fait, peu importe qu’il y ait de .htpasswd ; la faille ne se situe pas à ce niveau.

Souvenez-vous de ce que nous avons vu plus haut. Nous avons vu qu’Apache interprétait toutes les requêtes qu’il ne comprenait pas comme des requêtes GET. Ainsi, nous pouvons utiliser cela à notre avantage pour accéder à la page protégée sans s’authentifier !

Exemple : imaginons que nous avons un .htaccess rudimentaire de ce type dans le même dossier :

<Limit GET POST>
Deny from all
</Limit>

Logiquement, ce fichier est censé interdire tout accès aux pages du dossier. Le hic, c’est que seules les requêtes GET ou POST sont concernées… Tentez d’accéder à la page avec le navigateur : vous obtenez une erreur 403, puisque votre navigateur envoie implicitement un GET. Maintenant, envoyez une requête incorrecte avec un outil comme Netcat :

n1Mp0rTeKwa  http://127.0.0.1/~trance/vuln/ HTTP/1.1

Host: 127.0.0.1

Et vous obtiendrez la réponse suivante :

<h1>Bonjour !</h1>

Voila donc comment contourner la protection… Simple, n’est-ce pas ? Le pire, dans tout cela, c’est que la majorité des webmasters protègent leurs sites de cette façon. Et j’en faisais partie, jusqu’à ce qu’on me le signale

Correction

La correction est ultra-simple : n’utilisez pas l’instruction « limit » quand vous voulez restreindre l’accès à un fichier ou dossier ! Bannissez les lignes « <Limit GET POST> » et « </Limit> » de vos fichiers .htaccess et vous éviterez ce genre de problèmes.

D’ailleurs, la documentation d’Apache précise bien qu’en général, il ne faut pas utiliser <Limit> lorsque l’on cherche à restreindre l’accès. Je cite : « In the general case, access control directives should not be placed within a <Limit> section. »

Limites

Un petit bémol cependant : pour le moment, nous n’avons pas trouvé le moyen de fausser les requêtes POST en injectant des données. Ainsi, si vous avez des formulaires POST protégés par des .htaccess, ils sont à priori sûrs. Mais je vous conseille quand même de patcher vos .htaccess en retirant les lignes « <Limit> » un peu trop dangereuses…

D’autre part, je suis loin d’être un expert en configuration Apache. Il est possible qu’il existe une option demandant à Apache de refuser systématiquement toutes les requêtes qui ne sont pas comprises. Si vous la connaissez, vous pouvez laissez un commentaire, cela m’intéresse…

Merci encore à Geo pour m’avoir averti de la présence de la faille sur GITS !

Ceux qui ont déjà eu des problèmes liés à #include savent de quoi je parle… Qu’y a-t-il de plus énervant que de voir tout un projet se recompiler alors que l’on vient juste de toucher à un seul fichier d’en-tête ? J’entends déjà certains me répondre sans hésiter : «Quand ça ne compile plus à cause d’inclusions et de dépendances circulaires !», et ils ont probablement raison… Le but de ce billet est d’illustrer les problèmes les plus courants que l’on peut rencontrer en C++ et de proposer des solutions plus ou moins automatiques pour s’en sortir. Je vais commencer par illustrer les problèmes de base et leurs solutions respectives, pour finalement converger vers une solution globale, comportant certaines règles à suivre qui permettent de résoudre les problèmes de ce style. Notez que l’approche de ce billet est progressive et que la solution optimale est donnée à la fin.

En fait, après avoir été confronté à des problèmes de ce type et après avoir galéré à les résoudre, je me suis rendu compte que je ne maîtrisais pas comme il le fallait les actions du préprocesseur. Ce qui est plutôt gênant, quand arrivé à plusieurs milliers de lignes de code le projet refuse de compiler. En effet, dès que les projets atteignent une taille conséquente, la prise de tête peut rapidement commencer. Voici les principaux problèmes liés à l’inclusion :

Inclusion multiple

Le premier type de problème se produit quand un fichier se retrouve inclus plusieurs fois. Il est tellement classique que tout le monde le connaît par coeur, et place donc des directives pour se protéger des inclusions multiples (les traditionnels #ifndef, #define et #endif). Je ne m’éternise pas là dessus, j’imagine que je ne vous apprends rien.

Inclusion circulaire (agrégation, composition, utilisation…)

Un problème plus vicieux peut néanmoins apparaître lorsqu’un fichier se retrouve inclus avant un autre, ce dernier ayant besoin du premier. Ce genre de problème arrive lorsqu’on déclare par exemple des classes possédant chacune une référence ou un pointeur vers l’autre. Le compilateur étant par définition bête, il inclura comme il se doit les deux fichiers, mais inéluctablement, la définition d’une classe se retrouvera avant celle de l’autre. Et ça, le compilateur n’aime pas, puisqu’il tient absolument à ce que tous les symboles aient été déclarés à priori. Pour contourner ce genre de problèmes, on place simplement une directive non pas du préprocesseur, mais du langage C++ :

class MaClass;

Cette directive précise juste qu’il sera question d’une classe nommée MaClass dans la suite, et que le compilateur finira par trouver sa définition avant la fin de l’analyse syntaxique. On nomme cette directive la « forward declaration ». Elle doit bien évidemment être placée avant chaque classe et doit être répétée autant de fois qu’il le faut pour être certain que chaque symbole utilisé dans la définition de la classe ait bien été déclaré au préalable.

Il est important de noter que cette solution n’est valable que lorsque l’on utilisera des pointeurs ou des références sur des objets, qu’ils soient des paramètres de méthodes ou des types de retours. Dans ces cas là, la directive #include n’est même plus nécessaire. Ce point sera détaillé plus loin.

Dépendance et inclusion circulaire

Il s’agit d’un cas particulier de l’inclusion circulaire que nous venons de voir, mais il faut comprendre qu’il y a une nuance supplémentaire par rapport à la simple inclusion. Il y a en effet la notion de dépendance ; j’entends par là qu’une classe nécessite absolument la déclaration d’une autre, et que cette déclaration doit avoir eu lieu avant. Dans le problème précédent, peu importe l’ordre dans lequel le préprocesseur inclut les fichiers, l’un sera placé avant l’autre et cela ne gênera pas le compilateur. Cependant, il existe certains cas de force majeur, où le compilateur nécessite absolument la définition préalable d’une classe ; c’est notamment le cas de l’héritage, mais également des constantes (#define) et des structures. Imaginez qu’une classe B, définie dans un fichier B.h hérite d’une classe A définie dans A.h. Naturellement, B.h inclut A.h, et cette inclusion est absolument nécessaire pour que le code soit compilable. Si vous aviez fait l’inverse, c’est à dire inclure B à partir de A, cela n’aurais pas marché, même avec la directive « class ».

Supposez un instant que dans B.h vous ayez inclus le fichier A.h dans le bon sens, mais que A.h inclut un certain nombre de classes, chacune incluant une autre pour finalement former une chaîne d’inclusion qui finirait par inclure B.h… Ce serait très gênant, car la compilation de B aurait beau aboutir, celle de A bloquerait. En effet, Lorsque le préprocesseur inspectera A.h en dépliant le code inclus par les #include, il finira par inclure B.h. Or B.h définit la classe B qui hérite de A… alors que la classe A n’a finalement jamais été trouvée jusqu’ici ! Et là, c’est le drame…

Je n’en vois que deux solutions pour se sortir de ce pétrin. La première, que je qualifierais de « pas propre » consiste à déporter le 1er #include gênant de A.h après la définition de la classe A ; autrement dit le mettre en fin de fichier. Cette solution est sale car non seulement elle oblige à séparer certaines directives ou inclusions qui doivent absolument être au début du fichier des autres qui posent problème. C’est une solution qui peut marcher… Mais je pense que ce n’est vraiment pas la bonne méthode à prendre, et qu’elle risque même de reporter le problème à plus tard, quand le projet aura encore grandi et que la complexité du graphe d’inclusions sera devenu inextricable. Je préfère nettement la 2ème que voici…

LA solution

Quelle est donc la solution miracle ? En fait, il s’agit simplement de limiter au maximum les inclusions entre les fichiers d’en-tête, en revenant aux principes de base de la compilation C/C++. Considérez un cas simple : A.cpp qui inclut A.h dans lequel se trouve la définition d’une classe. Imaginez qu’A.h nécessite d’autres classes, qui sont incluses par A.h. Pour fixer les idées, nommons C.h un des fichiers inclus par A.h Finalement, A.cpp et A.h vont être compilés ensemble pour produire le même fichier objet ; il semble donc équivalent d’inclure C.h à partir de A.h ou de A.cpp, puisque le résultat sera le même. Et pourtant, c’est là que se situe toute la différence… En effet, si l’on déplace le #include « C.h » de A.h dans A.cpp, on a réussi à éliminer une inclusion de A.h. Du coup, il faudra probablement mettre une directive « class C; » en tête de A.h, mais c’est tout de même nettement mieux que d’introduire une inclusion qui risque de provoquer des problèmes du style de ceux que l’on vient de voir ! Ainsi, la règle à suivre est la suivante :

Réduire au minimum vital les inclusions dans les fichiers d’en-tête (.h) en les déportant dans les fichiers d’implémentation (.cpp).

C’est une règle toute bête,mais qui simplifie énormément la vie lorsque l’on développe un projet C ou C++. Le but est ainsi de supprimer le maximum (voire toutes) les directives #include des headers pour éviter les inclusions circulaires. Pour que cela compile, il sera nécessaire de rajouter les directives du type « class X; » en tête des fichiers d’en-têtes, mais qu’importe ! Ces directives sont « gratuites », dans le sens où elles ne risquent pas d’introduire des problèmes.

Concernant l’héritage, nous avons vu qu’il était absolument nécessaire qu’une classe mère soit définie avant une de ses classes filles. C’est pourquoi dans ce cas, on pourra se permettre de conserver la directive #include dans le fichier d’en-tête, afin d’éviter d’avoir à inclure la classe mère dans chaque fichier .cpp utilisant cet en-tête. Mais à ma connaissance, c’est le seul cas où la règle précédente ne s’applique pas.

Et finalement, on s’aperçoit que l’on peut encore mieux faire, en élaguant au maximum le graphe d’inclusions. En effet, il est possible de supprimer les inclusions de classes (qui se trouvent désormais dans les .cpp) lorsque la classe n’est utilisée qu’en tant que pointeur, référence, et qu’aucune méthode n’est utilisée. Autrement dit, si une classe A possède une méthode qui prend un paramètre un pointeur vers un objet de type B, et que cette méthode n’utilise ni les méthodes ni les attributs de B, alors il n’y a pas besoin d’inclure B.h dans A.cpp. Un simple « class B; » suffira, et il sera du coup placé dans A.h vu que le prototype de la méthode y sera déclaré. Et en fait, c’est tout à fait logique : si l’on n’utilise pas les membres de B, et qu’il ne s’agit que d’un pointeur ou d’une référence, le compilateur n’a aucunement besoin de connaître la définition précise de B, puisque pointeurs et références occupent tous la même place en mémoire.

Pour résumer la méthode, voici la solution générale pour résoudre la grande majorité des problèmes d’inclusions :

• Avant tout, chaque fichier d’en-tête doit comporter les classique directives #ifndef, #define et #endif pour s’assurer qu’il ne sera pas inclus plusieurs fois.
• Aucune directive #include ne doit apparaître dans un .h, sauf si une de ces conditions est satisfaite :
  • ce fichier .h déclare une classe qui hérite d’une autre classe
  • il nécessite la définition de constantes (au sens #define) ou de structures définies dans un autre .h.
  • la classe qu’il déclare comporte comme attribut un objet d’autre classe (et non pas un pointeur ou une référence vers celui-ci)
• Hormis ces 3 cas, il faut déporter les inclusions dans les fichiers .cpp.
• Pour permettre la compilation du projet, il faut placer en tête des fichiers .h (avant la déclaration de la classe) autant de directives « class X; » que nécessaire, où X est le nom d’une classe utilisée dans les méthodes du .h.
• Si certaines méthodes d’une classe A utilisent uniquement références ou des pointeurs sur des objets de type B, sans accéder aux membres (attributs ou méthodes) de B, il n’est pas nécessaire de placer une directive #include dans A.cpp. Un simple « class B; » suffit dans A.h.

En fait, on peut se souvenir simplement de ces règles en réfléchissant un minimum. Mettez-vous à la place d’un compilateur : quelles informations vous faut-il pour pouvoir compiler une classe ? Comme un des rôles capitaux d’un compilateur est d’allouer la mémoire, il faut nécessairement toutes les informations concernant la taille des objets. Si un objet A agrège (contient) un objet de type B, on comprend facilement que la taille de l’objet A sera calculée en fonction de la taille de B, donc l’inclusion de la classe de B est inévitable. Idem pour les héritage. Mais quand il s’agit de simples pointeurs et références, pas besoin de la définition complète, puisque tous les pointeurs et références occupent la même place en mémoire (celle du bus d’adresse de la machine).

Au final, l’application de cette méthode permet de démêler le graphe d’inclusions de son projet de façon relativement simple et automatique. Il s’agit de respecter ces règles de développement dans le but de limiter au maximum les dépendances entre fichiers. Les adeptes des gros projets savent combien il est pénible de voir tous les modules d’un projet se recompiler lorsqu’ils viennent de changer une constante dans un fichier d’en-tête… Ce genre de problème est très souvent du à une mauvaise organisation des inclusions entre fichiers sources, ce qui induit une chaîne de dépendance énorme, provoquant la recompilation quasi-totale des sources. Dommage, quand on utilise les outils du style « Makefile » dont le but est justement de ne recompiler que ce qui est nécessaire.

J’espère que cette technique permettra d’en aider plus d’un. En y réfléchissant, elle paraît évidente, mais l’expérience montre le contraire… Une chose est sûre : si je l’avais apprise dès le début, j’aurais économisé un certain temps de débogage. Mais d’un autre côté, le fait de s’être arraché les cheveux dessus me garantit que je ne suis pas prêt de l’oublier…

Avec un ami, nous avons eu une idée commune : tant qu’à faire une application de simulation, autant se faire plaisir et la réaliser en 3D. Fans des technologies libres, nous avons donc choisi OpenGL et Glut. Nous avions tous les deux une petite expérience en OpenGL, pour ma part ce fut mon deuxième projet C++/OpenGL, bien que je trouve bien plus complexe que le 1er. Étant donné que nous n’avions pas des talents d’artistes, nous avons choisi de faire simple pour ce qui était de la représentation du monde et des individus. Les adeptes de Glut ou plus généralement de la 3D connaissent probablement la fameuse Théière de l’Utah utilisée dans un certain nombre d’applications 3D. Ce modèle étant déjà présent par défaut dans la bibliothèque GLUT, nous avons décidé de l’utiliser pour représenter les individus de nos colonies. Et nous en avons profité pour baptiser notre projet «Teapot Colony Wars».

Nous avions le choix du langage, et nous avons choisi le C++ non seulement pour sa rapidité, sa portabilité, mais aussi parce que nous souhaitions progresser dans ce domaine. Et tant qu’à faire, nous l’avons développé dans le but de le diffuser sous licence GPL 2, pour qu’il continue à vivre et évoluer si certains veulent le reprendre. De plus, nous avons vraiment eu la volonté de développer un projet en nous rapprochant du monde professionnel, tout en n’utilisant que des logiciels libres. Nous avons utilisé Subversion, un excellent outil de gestion de versions qui nous a bien simplifié la tâche pour le développement, ainsi que Doxygen, pour la génération de la documentation. Le rapport de conception a été réalisé en LaTeX, et la compilation de l’exécutable a été grandement facilité par l’emploi des Autotools (AutoConf, AutoMake, …).

Au final, Teapot Colony Wars, c’est :

• 96 fichiers sources (uniquement les .h et .cpp)
• Un diagramme de 45 classes
• Plus de 9600 lignes de code C++
• Un délai de 6 semaines pour réaliser le projet (pendant lesquelles nous avons eu des examens…)
• Plus de 280 heures de travail
• 268 révisions dans le dépot Subversion
• Une documentation PDF de 449 pages générée par Doxygen
• Un rapport de 28 pages décrivant la modélisation et nos choix conceptuels

Nous avons profité de la livraison du projet pour publier la version 1 sur Sourceforge.net. Voici quelques unes des caractéristiques de l’application :

• Le monde est composé de plusieurs colonies, chacune ayant sa couleur.
• Chaque colonie peut créer des individus qui possèdent des caractéristiques propres comme sa taille. Une colonie consomme de la nourriture pour créer un individu.
• Le monde est composé d’une grille de cellules qui ont chacune des propriétés. Certaines sont inaccessibles (murs), d’autres contiennent de la nourriture qui se renouvelle au fur et à mesure de la simulation (certaines sont à renouvellement instantané, mais pas d’autres). Certaines cases sont des couloirs et inaccessibles aux individus trop grands.
• Les individus évoluent selon certaines stratégies comportementales que la colonie leur impose. Leur but est de trouver de la nourriture et de la ramener à la colonie. Mais à chaque pas, un individu consomme de la nourriture proportionnellement à sa taille.
• Chaque individu ne peut voir que les 8 cases adjacentes et a une très petite mémoire : il ne peut se souvenir que de la dernière case qu’il a franchie. Mais pour l’aider, il peut déposer des phéromones sur son passage. Chaque colonie définit ainsi 3 phéromones qui ne peuvent être comprises que par ses individus. Chaque phéromone a une durée de vie et se dégrade au fur et à mesure, jusqu’à disparaître.
• Quand deux individus ennemis se croisent, il y a combat. C’est le plus fort qui gagne ! Le vainqueur peut alors se nourrir du cadavre de ses adversaires.
• L’utilisateur peut à sa guise faire une offrande en déposant une source de nourriture sur le terrain.
• Il était demandé de tester deux stratégies différentes pour les individus. Les algorithmes heuristiques, qui peuvent être simples mais souvent imparfaits, et les algorithmes génétiques, consistant à définir des gènes pour les individus et effectuer un brassage génétique de la population en sélectionnant les meilleurs.

Les commandes souris et clavier du simulateur sont les suivantes :

• Pavé numérique (4, 6 8, 2) : déplacements horizontaux et verticaux
• Molette ou touches + et – : zoom
• Maintien de Ctrl et défilement de la molette (ou + et -) : inclinaison verticale
• Maintien de Ctrl + Clic gauche ou droit : rotation à gauche ou à droite
• Espace : Activer / enlever le mode pause
• Clic gauche : effectuer une itération
• Étoile (*) : donner une offrande aux individus, qui apparaîtra sur le curseur de sélection (tore en bleu clair)

Nous sommes globalement très satisfaits de ce projet, car nous avons pu finir dans les temps, même si nous aurions aimé rajouter quelques fonctionnalités supplémentaires. Mais cela restera tout à fait possible étant donné la grande extensibilité de notre application. En effet, grâce à un usage intensif de toutes les techniques propres à la modélisation orientée objet, comme le polymorphisme et les designs patterns, nous avons construit un ensemble de classes génériques, qui peuvent s’apparenter à un framework. Il est ainsi tout à fait possible de rajouter à moindre coût des nouvelles cases, des nouveaux types d’individus, changer leur représentation (pour ceux qui n’aiment pas les théières…), changer le système de combat, et même pourquoi pas rajouter de nouveaux mouvements (comme le saut ou la téléportation).

Si cela vous intéresse, vous pouvez télécharger la version 1.0 du projet, tel que nous l’avons rendu à nous professeurs. Les sources sont disponibles, ainsi que les exécutables pour Linux et Windows. Attention toutefois pour ce dernier, il semble que la portabilité soit encore un tout petit peu imparfaite ; en effet nous n’avons pas encore eu le temps de changer quelques détails qui peuvent bloquer la génération de l’exécutable selon le compilateur utilisé. Mais nous allons bientôt remédier à cela…

Voici les liens pour accéder aux ressources du projet :

• Site du projet sur Sourceforge.net
• La page de téléchargement
• Le dépot SVN accessible en ligne
• Les détails pour effectuer un check-out du SVN
• La documentation HTML en ligne

Pour lancer l’application sous Windows, vous avez juste à lancer l’exécutable. Sous Linux, pensez toutefois à lancer l’application en mode console pour éviter les surprises ; en effet, il faut que le dossier de textures se trouve dans le dossier courant.

Pour compiler le projet sous Linux, assurez-vous de disposer des bibliothèques pour le développement d’application graphiques, en particulier Glut. Décompressez l’archive dans un répertoire, puis tapez les instructions suivantes :

$ ./configure --prefix=$HOME

$ make

$ make install

L’application s’installera automatiquement dans votre homedir, dans le dossier bin. Si la documentation vous tente, vous pouvez générer le HTML et les fichiers LaTeX en tapant :

$ doxygen Doxyfile

Ensuite, placez-vous dans le dossier doc/latex et tapez simplement :

$ make

Le PDF résultat se nomme «refman.pdf» et sera généré dans le dossier courant. Bonne lecture…

Un site internet du projet verra peut-être le jour au courant de l’année, si je trouve un peu de temps à y consacrer. N’hésitez pas à me faire part de tous vos commentaires sur ce projet. Profitez de sa licence et faites le vivre !

Le premier s’appelle PHiMX et est un outil en ligne de commande pour reverser une application PHP et générer son diagramme de classes UML au format XMI. C’est particulièrement intéressant quand on a développé une application sans prendre le temps de faire un diagramme de classes et qu’on souhaite s’y retrouver, ou bien quand on a généré le code PHP mais que l’on souhaite changer d’outil de modélisation pour migrer par exemple vers un outil libre. Le logiciel est disponible en LGPL et est installable via Pear en tapant la commande suivante :

pear install http://phimx.sourceforge.net/PHiMX-1.0b1.tgz

Rappelons que si vous n’avez pas Pear, vous pouvez l’installer sur la plupart des distributions Linux via le système de paquets habituel, par exemple sur Debian/Ubuntu :

sudo apt-get install pear

Le fichier XMI produit sera alors utilisable par les outils courants de modélisation UML. Pour ne citer que les libres et gratuits : Umbrello, BOUML, et StarUML.

• Site officiel de PHiMX
• Manuel en Français
• Source : La dépèche sur Linuxfr.org

Le deuxième, baptisé Jelix, est en fait un framework conçu pour PHP >= 5.2. Ce framework respecte l’architecture Modèle – Vue – Contrôleur, supporte les templates, implémente la correspondance directe entre les objets et les tables d’une base de données relationnelle, et contient entre autres un générateur de formulaires automatique à partir d’un fichier XML. Mais sa spécifié la plus intéressante (à mes yeux) est qu’il est très rapide car volontairement axé sur l’optimisation des performances. La version Gold contient à cet effet une extension PHP spécialement concue pour augmenter encore la rapidité de l’application. En fait, il est disponible en 3 versions plus ou moins optimisées, toutes sous LGPL. Le site officiel, en Français, contient entre autre une FAQ, une présentation du framework ainsi qu’un mini tutoriel pour apprendre à s’en servir.

• Présentation de Jelix sur le site officiel
• Source : La dépèche sur Linuxfr.org