Blog Haypo

Du fuzzing, toujours plus de fuzzing ! Plus je triture les programmes et plus je trouve de bugs. Je n'ai pas encore assez de recul pour dire si c'est positif ou non. En tout cas, je n'arrête pas de publier des rapports de bugs.

Un collègue m'a conseillé de contacter des organismes s'occupant de diffuser les vulnérabilités pour que tous les gens concernés soient au courant et prennent les dispositions nécessaires. Le premier, FrSIRT, m'a répondu en 2h et le second, Securina, en 4h. Chapeau ! Et après quelques échanges d'emails pour leur donner des détails, deux bulletins de sécurité ont été publiés :

• Libexif Image Handling Integer Overflow Vulnerability (10 mai)
• ClamAV OLE2 Parser Denial of Service (11 mai)

Je ne suis pas peu fier de lire mon nom sur ces sites Internet :-) Le bug ClamAV (anti-virus libre pour Windows et Linux) est inquiétant car aucun nouvelle version n'a été publiée pour le corriger. Si ce bug est exploité, il peut rapidement mettre un serveur anti-virus hors-service : consommation massive de ressource processeur et de disque dur.

Je suis de plus en plus persuadé que tous les programmes sont bogués et qu'un certain nombre de bugs sont exploitables par des pirates informatiques. Ce n'est vraiment pas rassurant car tous les types de documents sont affectés. Pour ne citer que les plus courant : on peut planter un programme avec un simple document PDF voir même une image JPEG !

Je cherche et je rapporte les bugs pour contribuer au libre mais également pour éviter que des pirates le fassent à ma place et exploitent les bugs. Comme je n'aurai jamais le temps de tester tous les programmes, je pense plutôt à publier mes outils de test pour que d'autres poursuivent mon travail. J'ai déjà commencé par mettre en place un serveur Subversion ainsi qu'une plateforme Trac pour publier mon travail. Mon nouveau projet est hébergé sur mon serveur perso à l'adresse : fusil.hachoir.org. Consultez mon tableau de chasse : liste des bogues trouvés par la méthode du fuzzing.

Suite de mon initiation au fuzzing. J'ai continué des tests pour trouver toujours plus de bug. J'avais lu par-ci par-là que les programmes ont de très nombreux points d'entrée, pas uniquement le clavier et la souris. J'avais testé les fichiers, j'ai alors testé les variables d'environnement. J'ai d'abord écrit un script bash utilisant strace (puis ltrace) pour traquer les appels à getenv() (entre autres). À partir de la liste des variables, j'en tenté de faire planter les programmes en passant des valeurs invalides (grand nombre, très longue chaîne, etc.). Le premier programme à planter était dpkg avec « COLUMNS=10000000 dpkg -l ».

J'ai mis une bonne grosse semaine à isoler le bug. J'ai compris que le bug venait de vfprintf() mais je n'ai pas compris dans quel cas on pouvait le reproduire. J'ai isolé la chaîne de formatage : on peut alors reproduire le bug avec la fonction printf de bash ou /usr/bin/printf : « printf "%-1.25000000s" "Hello" ». En creusant encore plus, jusqu'à l'assembleur (on peut pas creuser plus profond :-)), j'ai isolé la ligne C qui posait problème. C'était un appel à mbstowcs() utilisant un tampon local de la forme « wchar_t ignore[prec]; », or prec vaut 25000000. En clair : la glibc tente d'allouer 25 Mo dans la pile alors qu'elle fait que 8 Mo et que Linux ne sait pas la faire grossir automatiquement (honte à lui). Je pensais justement que c'était un appel à alloca() mais je faisais fausse route. Conclusion : utilisez la pile avec parcimonie. Évitez absoluement la fonction alloca() et la notation C « type var[taille]; » où taille est supérieur de 4096 ou une variable contrôlable directement ou indirectement par l'utilisateur.

J'ai rapporté le bug et il a été corrigé en 48h par Ulrich Drepper (mainteneur de la libc). Encore une belle preuve de la réactivité des développeurs de logiciel libre.