Blog Haypo

Annonce d'une nouvelle version de Fusil

Estimant que la réécriture du fuzzer Fusil est achevée, j'ai lancé une compagne de buzz pour faire connaître l'outil. J'ai posté un courriel sur les listes de diffusion fuzzing et pen-test. J'ai écrit un journal linuxfr.org. J'ai aussi contacté personnellement des auteurs de fuzzers. Enfin, j'ai enregistré le projet sur Cheeseshop, Ohloh et Freshmeat.

Logs Apache et scripts Python

Hébergeant les sites *.hachoir.org sur mon propre serveur, je peux facilement en consulter les logs Apache. D'ailleurs, j'écris depuis plusieurs mois des scripts Python pour les analyser : apache_log. Je m'intéresse plus particulièrement à l'origine des visiteurs. Apache enregistre l'IP du visiteur, son « user-agent » et l'url d'où il provient (referrer).

Lassé de taper « host 84.74.168.(...) » pour voir d'où vient chaque visiteur, j'ai écrit un nouveau script (host.py). Il prend en entrée un fichier de log et génère un rapport HTML listant les reverse-dns triés selon le nombre de hits. Les résultats du reverse-dns sont mis en cache durant une semaine (stocké dans un fichier). Le reverse-dns est simplifié : « lns-bzn-29-82-248-234-136.adsl.proxad.net » est affiché « www.proxad.net ». Ceci permet de regrouper les visiteurs venant du même réseau. Consultez parser.py et host.py pour les détails

Analyse des visiteurs de fusil.hachoir.org

En à peu près 24h, j'ai vu passer :

• Laboratoires de recherche : France Telecom (R&D), INRIA, INRA, Motorola Laboratories, CERN, CERT, CEA
• Entreprises : Virgin Media, Ericsson, Microsoft, Roche, STMicroelectronics, Alcatel, FlightSafety, Digital Defense, Daimler, MWR InfoSecurity, Cisco, Rockwell Collins, VMware, TippingPoint, EADS, Juniper, Qualys, CXR Anderson Jacobson, atsec
• Agences gouvernementales : US Office of Personnel Management (OPM), Conseil de l'Europe, Sandia National Laboratories (États-Unis)
• Pays : France, États Unis, Israël, Turquie, Belgique, Italie, Allemagne, Suisse, Russie, Brésil, Ukraine, Japon, Argentine, Chine, Nouvelle Zélande, Finlande, Hongrie, Canada, Taïwan, Pologne, Philippines, République dominicaine, Île Christmas
• Universités :
  • France : Université de Technologie Compiègne ; Université de Rennes 1 ; CNAM ; Grande ecole d'ingenieurs informatique electronique telecoms reseaux biomédical ; Université de Versailles Saint-Florent-en-Yvelines ; Université Lille 3 ; Université de Limoges ; École Nationale Supérieure des Télécommunications de Bretagne ; Académie de Rouen
  • Autres pays : Universität Hamburg (Allemagne) ; Facultés Universitaires - Notre Dame de la paix - Namur (Belgique) ; Universiteit van Amsterdam (Pays-bas) ; Cranfield University (Angleterre) ; National Chiao Tung University (Taïwan) ; University of California Berkeley (États-Unis) ; Oxford Brookes University (Angleterre) ; Massey University (Nouvelle Zélande)

(je me suis aidé de la liste Wikipédia des domaines de premier niveau pour les domaines nationaux que je ne connaissais pas)

Que faut-il comprendre de toutes ces informations ? Bah déjà que le fuzzing intéresse beaucoup de monde :-) Sinon, ce n'est pas parce qu'un employé quelconque de Microsoft a cliqué sur mon site que le prochain Windows sera exempt de bug. Je ne pense pas non plus que ces informations soient très fiables, beaucoup de traffic provient de robots automatiques qui parcourent Internet nuit et jour. Par contre, je dois avouer que je suis plutôt fier de voir passer des hits en provenance des réseaux du CEA, EADS et du CERT :-)

Cet article détaille l'architecture d'une nouvelle implémentation de mon outil de fuzzing « Fusil » : un système multi-agents qui devrait éviter la lourdeur des applications monolithiques.

Système multi-agents

Pour avoir mis les doigts dans de grosses applications (plus de 10.000 lignes de codes), je peux dire qu'une application monolithique est difficile à déboguer et à faire évoluer. L'architecture d'un logiciel repose sur un graphe d'objets liés les uns et autres à la sauce spaghetti. Modifier une classe ou le prototype d'une fonction impacte des dizaines d'autres classes et fonctions. Bien que des outils de refactoring facilitent la répercution des changements sur l'ensemble du projet, une architecture plus modulaire nous délesterait de cette tâche ingrate.

Un système multi-agents (SMA) est une simulation qui implique des dizaines d'agents simples qui communiquent entre eux par des événements. Le gros avantage est qu'un agent est (quasiment) aveugle : sa vision de l'environnement est volontairement limitée. En particulier, un agent n'a pas accès aux données des autres agents. Ce concept issu de la recherche en intelligence artificielle peut être adapté à des programmes plus communs. Comme j'ai repris mon projet Fusil depuis zéro (pour la 3e fois), j'ai décidé d'implémenter un SMA simple en Python pour mes besoins.

Agents dans Fusil

Pour rappel, Fusil est un générateur d'erreurs servant à rechercher des bugs dans un logiciel (Fusil est un fuzzer). Dans Fusil, tout est agent. Lorsqu'un agent émet un événement, ce dernier est mis en attente dans le MTA (Mail Transfer Agent). L'événement n'est transmis aux destinataires qu'au cycle de simulation suivant. L'agent Project est responsable d'exécuter la simulation : il demande à chaque agent de lire sa boîte de messages puis d'exécuter leur méthode live(). MTA et Project sont eux-même des agent et peuvent donc émettre et recevoir des événements. Exemples d'événements : « session_start », « process_create », etc.

Les agents de type Session sont crées pendant une session et sont automatiquement détruits à la fin d'une session. Les agents de type Project sont conservés toute la durée de vie du projet. Par contre, ils sont désactivés quand aucune session n'est active : ils ne peuvent plus communiquer (ni émettre ni recevoir de messages) et leur méthode live() n'est plus appelée. Enfin, lorsque le projet est fermé, les agents Project sont détruits. Ce découpage (Project/Session) permet de gérer simplement la durée de vie des données. En particulier, on s'assure que les données sont détruites au bon moment.

Exemples d'agent

• CreateProcess : lance un programme. Tue le processus en cas de timeout (10 secondes par défaut).
• WatchProcess: surveille un processus et en particulier sa mort (le processus a quitté ou a été tué par un signal fatal)
• Syslog : surveille les logs systèmes (/var/log/message et /var/log/syslog)
• TimeWatch : surveille la durée d'une session
• MangleFile : injecte des erreurs dans un fichier

Système de notation

Les agents de surveillance attribuent une note à la session entre -100% et +100%. La note globale est la somme de toutes les notes. Si elle dépasse un seuil (+50% par défaut), la session est considérée comme un succès et est stoppée. Certains agents peuvent demander explicitement la fin d'une session : après un timeout ou la mort du processus par exemple.

Projets de fuzzing

Un projet Fusil est une configuration pour fuzzer une application. Une douzaine de projets sont disponible : ClamAV, printf, MySQL, rpm, etc. Les projets sont beaucoup plus diversifiés que les exemples des précédentes implémentations de Fusil. La nouvelle architecture plus modulaire et générique permet de configurer très finement chaque composant (agent).

Le moteur du SMA de Fusil est encore en gros chantier. Il risque encore de beaucoup évoluer ces prochaines semaines pour s'adapter au mieux aux besoins du logiciel. Note : Fusil s'autorise de multiple digressions par rapport au SMA parfait pour simplifier la vie du programmeur.

Comme je commençais à accumuler pas mal de liens intéressants sur la gestion de la mémoire, je me suis décidé à écrire un article. J'espère qu'il vous sera utile, au moins pour la culture générale.

Multithreading et malloc()

L'implémentation actuelle du célèbre allocateur de mémoire malloc() de la GNU libc est peu performante pour un programme multi-threadé. En particulier, la mémoire se fragmente facilement et l'allocation de mémoire est donc de plus en plus lente. Google a développé sa propre version de malloc() : tcmalloc. Elle est disponible dans la suite google-perftools sous la nouvelle licence BSD. Côté points noirs, tcmalloc utilise directement 6 Mo au démarrage pour son usage interne, et elle ne rend jamais la mémoire au système !

La prochaine version de FreeBSD (7.0) aura aussi un nouvel allocateur de mémoire : jemalloc, écrit par Jason Evans. L'implémentation actuelle de de FreeBSD est celle de Poul-Henning Kamp : phkmalloc. Vous trouverez une présentation de jemalloc dans l'article What's cooking for FreeBSD 7? Lisez également le papier écrit par Jason en avril 2006 : A Scalable Concurrent malloc Implementation for FreeBSD.

Selon un benchmark « NetBSD versus FreeBSD », les performances restent stables au delà de 4 threads (sur une machine ayant 4 processeurs) pour le nouvel allocateur de FreeBSD, alors que pour NetBSD et Linux les performances s'écroulent. En utilisant tcmalloc, les performances de Linux sont similaires à celle de FreeBSD.

La version actuelle de la GNU libc utilise ptmalloc2, implémentation inspiré de celle de Doug Lea (dlmalloc) version 2.7. La nouvelle glibc (version 2.6) utilise ptmalloc3 : 3e version de ptmalloc, basée sur dlmalloc 2.8.3 (date de 2005).

Mesure de la mémoire des processus

En avril 2007, Matt Mackall présentait son travail sur la quantification de la mémoire utilisée par un processus au Embedded Linux Conference. Il part du constat que les valeurs données par le noyau Linux n'ont que pas/peu de sens.

Il propose un patch pour le noyau qui permet de compter le nombre de processus partageant une page mémoire. La quantité de mémoire utilisée par un processus est alors le nombre de pages mémoire non partagées plus le nombre de pages partagées divisé par le nombre d'utilisations. Exemple : si 20 programmes utilisent une bibliothèque KDE de 30 Mo, la bibliothèque pèsera 30/20 = 1,5 Mo pour chaque processus et non plus 30 Mo comme c'est le cas actuellement ! Ceci permettra d'avoir une meilleure idée de la répartition de la mémoire. LWN.net propose un article détaillant la présentation de Matt.

Aux dernières nouvelles (voir les prévisions météo de Linux), le patch devrait être intégré dans Linux 2.6.25. La dernière version stable de Linux est la 2.6.23 et la 2.6.24 est en cours de développement. Il faudra être donc être encore un peu patient (ou alors recompiler son noyau à la main ;-)).

Astuce : Pour mesurer l'utilisation de la mémoire vidéo par les applications graphiques, utilisez le programme xrestop plutôt que top ;-)

Ce que tous les programmeurs doivent savoir au sujet de la mémoire

Ulrich Drepper, actuel mainteneur de la GNU libc travaillant pour RedHat, a écrit un article détaillant sur 100 pages la mémoire de nos jours (2007) : What every programmer should know about memory. Il a contacté le site Internet LWN.net pour publier son article. Pour une lecture plus confortable, l'article est découpé en 6 parties :

• Memory part 1: Commodity Hardware Today
• Memory part 2: CPU caches
• Memory part 3: Virtual Memory
• Memory part 4: NUMA support
• Memory part 5: What programmers can do
• Memory part 6: What programmers can do - multi-threaded optimizations

J'ai commencé à lire la 1ère partie qui est d'une excellente qualité. Par contre, c'est extrêmement technique et très détaillé. La première partie présente l'organisation logique d'un ordinateur en se concentrant sur le/les processeurs, la mémoire, le northbridge et le southbridge. Merci à toady de m'avoir indiqué ce lien ;-)

Noyau Linux

Le site linux-mm.org (Linux Memory Management) centralise les informations sur la gestion de mémoire par le noyau Linux. On y trouve les projets en cours de développement comme advanced page replacement. On y trouve aussi de très bonnes informations sur le gestionnaire de mémoire Linux, comme par exemple les articles OOM Killer (mécanisme qui désigne quel processus tuer quand la machine n'a vraiment plus de mémoire) et page fault handling. Rik van Riel a d'ailleurs publié une lettre ouverte invitant les universités à faire de la recherche fondamentale sur la gestion de la mémoire. Les algorithmes utilisés ne sont plus adaptés aux machines actuelles !

Et Python ?

Le gestionnaire de mémoire interne de Python 2.3 et 2.4, pymalloc, est bogué. Il ne rend jamais la mémoire au système ! Lisez le billet d'Evan Jones pour en savoir plus. Evan Jones a justement corrigé ce bug et son travail a été intégré dans Python 2.5. Lisez l'annonce d'Evan Jones et l'annonce de Tim Peters sur la liste de diffusion python-dev. Tim Peters a repris le travail d'Evan Jones, l'a corrigé et l'a intégré à Python.

Pour finir, voici deux outils permettant de tracer l'utilisation de la mémoire : PySizer et Heapy. Je ne les ai pas encore testé, mais ils sont certainement très instructifs. Lisez également le papier Heapy: A Memory Profiler and Debugger for Python.

N'oubliez pas d'utiliser régulièrement Valgrind sur vos programmes pour traquer les fuites de mémoire !

Depuis plusieurs années, je voyais des publicités pour le logiciel WinDev dans divers magazines d'informatique. N'ayant aucune connaissance l'utilisant, je m'étais toujours demandé quels en sont les usages. J'étais également étonné du peu de sites Internet dédiés à l'outil. Je me suis alors attardé sur le site Internet de PC SOFT pour récolter un maximum d'informations. Pour éviter de colporter des bêtises, j'ai pêché un maximum d'informations dans divers forums, en particulier le newsgroup fr.comp.developpement.agl.windev.

PC SOFT

PC SOFT est une éditeur de logiciel français basé à Montpellier. La société existe depuis 1984 et s'est fait connaître avec son éditeur d'écran pour MS-DOS : High Screen. Ce logiciel s'intègre à divers langages de programmation (C, Pascal, Cobol, ...). Il est doté d'une base de données appelée Hyper File. Renommé Hyper Screen en 1992, il servira de fondement à son successeur : WinDev. Ce dernier est qualifié d' « Atelier de Génie Logiciel » (AGL) par son éditeur. WinDev est constitué :

• d'un éditeur d'interface utilisateur
• d'un langage de programmation : le WLangage
• d'un éditeur de code source
• de la base de données Hyper File
• d'outils de modélisation (Merise et UML)

WinDev excelle dans la réalisation d'interfaces de saisie

Les captures d'écran et vidéos de démonstrations montrent qu'on peut dessiner facilement de belles interfaces. Chose délicate et pénible avec d'autres outils. Pour vous en faire une idée, visionnez la vidéo surcharge d'IHM et de code. De nombreuses fonctionnalités visent à améliorer l'interface utilisateur comme la mémorisation des valeurs saisies par l'utilisateur (persistance des champs) ou le grisage automatique des fenêtres inaccessibles.

PC SOFT soigne son image

[1997] Le webmestre du site Windev® Development Center, Pierre Fauque, est contacté par PC SOFT au sujet de son site Internet. Il utilisait le logo WinDev sans autorisation, le nom WinDev n'avait pas le suffixe ® (registred : nom déposé), et il n'était pas clairement indiqué que ce site n'est pas celui de PC SOFT. Lisez les échanges par courriel pour les détails.

[1999] En septembre 1999, un employé de la société Oriom pose une question au support PC SOFT sur les performances de WinDev. Il évoque une rumeur sur de mauvaises performances. On peut s'étonner de la formulation de la réponse de PC SOFT (copie sur archive.org) : « La rumeur à laquelle vous faite allusion est ridicule, dénuée de tout fondement, et pourrait s'interpréter comme du dénigrement ou de la diffamation ».

[2006] Marc Lussac, fondateur de la communauté developpez.com, expliquait en janvier 2006 que l'ouverture d'un forum WinDev ne pouvait se faire sans l'aval de son éditeur : « On aimerait bien avoir une rubrique Windev mais on n'a pas reçu l'autorisation de PC SOFT, (...) et sans autorisation on ne peut rien faire ». Le forum existe aujourd'hui, Marc a sûrement fini par obtenir l'autorisation en question.

[2007] Les articles Wikipédia concernant les logiciels PC SOFT sont régulièrement modifiés par PC SOFT en sa faveur depuis une adresse IP de l'entreprise (81.80.226.153). Plusieurs personnes s'en plaignent dans la page de discussion de WinDev.

L'affaire Beaussier

Cyril Beaussier était un utilisateur WinDev de longue date. Il appréciait l'outil jusqu'au jour où il a ouvert plusieurs sites Internet dénigrant PC SOFT et son produit phare WinDev. Il a publié ses sites sous le pseudonyme Gérard Menvussa (Gégé) :

• « WindeZ, le site critique » ayant de multiple miroirs :
  • http://windez.ifrance.com/
  • http://windez.iquebec.com
  • http://windev.zap.to/
  • http://windev.20m.com/
• « Extrême WinDev » : http://www.extreme.windev.free.fr/
• « W.I.F., Windev is free, Portail du monde libre sous Windev® » : http://windev.is.free.fr

En octobre 2002, PC SOFT arrive à faire fermer ces sites en l'exigeant au près des différents hébergeurs (sans prévenir Cyril par contre). Le 11 février 2003, Cyril reçoit une assignation en justice. Le 13 mars 2003, il perd le procès : on lui interdit toute diffamation de PC SOFT et de leurs produits, et la fermeture de ses sites Internet (ce qui avait déjà été fait). Cyril a écrit de nombreuses informations sur son procès dans son forum. Lisez également l'article WinDev Trivia de l'auteur néerlandais Peter.

L'association WinD'Asso

En octobre 2000, une soixantaine de personnes de divers pays (France, Belgique, Hollande, Italie, Afrique, Canada, États-Unis, ...) émettent le besoin de se regrouper pour être plus fort et plus efficace. Le 22 décembre 2000, les status de l'association WinD'Asso sont déposés auprès de la préfecture des Alpes-Maritimes.

L'association a, entre autres, constistué une liste des dysfonctionnements (bugs) des différentes versions de WinDev. À l'heure où j'écris ces lignes, on y trouve 115 bugs ouverts et 82 bugs fermés ce qui donne un total de 207 bugs référencés.

Marketing WinDev

Voici quelques phrases extraites du site Internet de WinDev :

• « AGL sans concurrence »
• « 100% des besoins sont couverts »
• « Horizon infini »
• « Gain productivité phénoménal »

WinDev est aussi une cascade de nombres : « AGL numéro un en France », « Développer 10 fois plus vite », « 100 clients témoignent », « 500 nouveautés » et le bouquet final « HyperFile 10 milliards d'enregistrements ».

Conclusion

On peut se demander pourquoi PC SOFT est tellement agressif quant à la protection de son image. Je vous conseille d'aller faire un tour dans les différents forums WinDev. Les discussions y sont souvent houleuses.

En attendant, je suis d'autant plus heureux de travailler sous Linux et de n'utiliser que des logiciels libres !

Les marques Windev®, Webdev®, Hyper File® sont déposées par la société PC SOFT.

Mise à jour, avril 2011 : L'employé de la société Oriom m'a demandé à ce que son nom soit retiré de cet article. J'ai contacté la CNIL : effectivement sa demande est légitime. J'ai donc supprimé son nom. D'ailleurs, le forum windev.wdscript.com a fermé en juin 2008. Extrait du message qu'on peut lire à la place du forum : « Un internaute m'ayant menacé de saisir la CNIL parce que certains de ses messages (dont il ne doit pas être fier) étaient archivés sur ce site, j'ai décidé de mettre un terme à la diffusion des archives de la mailing-list WinDev. Ce service était rendu à titre bénévole, et il est hors de question que cela me pose des problèmes à titre personnel à cause de cet excité (qui se reconnaîtra). L'aventure commencée en 2001 se termine donc en 2008. Ceux qui voudraient obtenir une version des +120000 messages archivés (c'est une base MySQL) peuvent me contacter sur ... »