URL: https://linuxfr.org/users/syj/journaux/compromission-de-code-source Title: Compromission de code source. Authors: syj Date: 2009年08月03日T12:49:07+02:00 Tags: Score: 11 Salut, Depuis quelques temps, je gère un projet libre sur SF. [http://sourceforge.net/projects/planningrh/](http://sourceforge.net/projects/planningrh/) Je le développe et le fait développer par mes stagiaires. Étant paranoïaque de nature, je me pose pas mal de question. Suite au journal sur la "SquirrelMail compromis...one more time !" de patrick_g ([http://linuxfr.org/~patrick_g/28619.html),](http://linuxfr.org/~patrick_g/28619.html),) je souhaitais réagir et vous faire de part de mes réflexions sur ce sujet. Avec un simple Login et mot de passe, on peut tout faire sur SF: - publier du code - publier des fichiers - administrer le site ... Je ne parlerais pas de la longueur du mot de passe qui peut être critique et qui est souvent présenté comme le point le plus important à tord. Le plus grand risque qu'offre une protection basée sur un login/mot de passe est que celui-ci se retrouve dans une base de données connu d'un potentiel attaquant. Ce potentiel attaquant a plusieurs moyen pour collecter ce type d'information: - vole via un KeyLogger. - récolte par un site malveillant ou compromis. Je me rappelle d'un article où leur d'une perquisition la police a trouvé une machine zombi hébergeant des centaines de millier de login/mot de passe. Il est plus rapide de tester une base de couple login/mot de passe que d'utiliser la force brut. D'ailleurs, une base de tous les login/mot de passes est "informatiquement" envisageable: 4 milliard d'humain, 1 à 10 mot passe par humain , chacun faisant 1 à 10 caractères. Dans le meilleurs des cas, 4 milliard * 10 * 10 = 400 milliard d'octet soit une base de 400 Go. Personnellement, j'ai un mot de passe qui est propre à SF. J'utilise ce compte uniquement à partir d'une machine que j'estime comme seine. Mais je peux difficilement garantir cette bonne pratique chez mes stagiaires. Je peux difficilement garantir que le compte de mes stagiaires n'a jamais été utilisé dans un contexte qui pourrait compromettre leurs login/mot de passe. Dernier point, je viens de découvrir que SF adhère à OpenID. Mes contributeurs pourraient avoir un compte identique sur Yahoo! , AOL, MySpace, ... Le seul moyen qu'il me reste pour garantir que mon code est non compromis, Il faut dans l'ordre d'importance: 1) M'assurer que la machine pour coder est seine. 2) Changer régulièrement de mot de passe. 3) Réaliser une audit régulière du code , en priorité celui modifié. 4) Signer les paquets que je publie. 5) Exécutez le programme sur une machine seine et m'assurer que celle-ci ne présente pas de signe de compromission à l'exécution Actuellement, je ne réponds qu'aux trois premiers critères. En conclusion , SF offre une grande facilité pour le développement et la publication de logiciel libre mais il pose un réel problème de sécurité. Enfin pour ceux qui pourrait penser que cette problématique n'existe pas dans le monde du logiciel propriétaire. Certes le problème de ce Login/Mot de passe n'est pas aussi important mais on perd la garantit fondamentale de pouvoir auditer le code ou d'espérer qu'un tiers compétent la fait. Dans l'ensemble tous les éditeurs que je côtoie ou que j'ai côtoyé dans mon métier d'admins d'une clinique, aucun ne semble respecter les bonnes pratiques qui permettent de garantir que les machines servant au développement reste seine. - Les dev sont quasiment toujours admins de leurs machines avec pleins de programme plus ou moins utile d'installé. - Quand on voit les librairies tiers qui sont intégrés à certains logiciels , il y a de quoi se poser des questions. Au moins avec les logiciels libres, on peut contrôler.