Les applications pendant leur cycle de vie sont le plus souvent sujettes à des bugs ou des failles de sécurité dues à des erreurs de programmation, des dysfonctionnements, etc.
Ces bugs et failles sont couramment découverts par d’autres tiers (experts en sécurité, testeurs, etc.) qui se chargent de décrire la faille, les risques et les conséquences que peut avoir une exploitation de celle-ci, ainsi que la fonction qui est à l’origine de la défaillance.
Face à de telles situations, le développeur doit le plus souvent essayer de mettre sur pied en fonction du degré de vulnérabilité un correctif de sécurité.
Cependant, il s’avère que souvent, le développeur ne s’aligne pas avec le rapport de l’expert en sécurité, affirme que les propositions faites par celui-ci sont inacceptables, ferme les yeux sur certaines failles en supposant qu’elles ne peuvent pas être exploitées ou qu’elles ne sont pas critiques, etc.
Un cas pareil pour l’application Calibre, un logiciel d’e-book libre et open source, qui organise, enregistre et gère les e-books sur plusieurs formats a attiré note attention.
Plusieurs vulnérabilités ont été découvertes et soumises au développeur du projet dans « calibre SUID mount helper », pouvant entrainer la suppression de n’importe quel répertoire vide sur le système, la création des répertoires root, la création et la suppression de « user_controlled _dir/.created_ by_calibre_ mount_helper » n’importe ou sur le système de fichier, la possibilité d’exécuter n’importe quel programme comme root.
Au lieu d’essayer de travailler de commun accord avec celui ayant soumis le rapport, le développeur du projet trouve dans un premier temps que certaines vulnérabilités ne sont pas des failles de sécurité, ou qu’elles ne peuvent pas être exploitées. Bref qu’elles ne sont d'aucunes importance.
Ensuite, il trouve que les mesures d’atténuation proposées par celui-ci sont inacceptables, et que finalement la menace (qui permet à des utilisateurs sans privilèges d’avoir un accès root) n’est pas critique.
Une telle situation et le nombre d’applications dont les versions s’enchainent souvent avec des failles de sécurité qui avaient déjà été découvertes ou qui ont été corrigées uniquement dès lors que la vulnérabilité et la preuve de réalisation (PoC) ont été divulguées publiquement, nous pousse à nous demander comment le développeur prend-il en compte le rapport des failles sur son programme ? Comment les classifie-t-il et fait-il appel à celui ayant découvert la faille pour apporter un correctif ?
Le rapport de failles sur Calibre et les échanges avec le développeur du projet
Les développeurs ignorent-ils trop les failles découvertes dans leur code ?
Prenez-vous en compte les remarques des autres ?
Les développeurs ignorent-ils trop les failles découvertes dans leur code ?
Prenez-vous en compte les remarques des autres ?
Le , par Hinault Romaric
Une erreur dans cette actualité ? Signalez-nous-la !