Heartbleed, encore et toujours une bombe à retardement pour internet

Guy Kindermans Rédacteur de Data News

Après l’émoi causé par Heartbleed au début de cette année, les solutions pour contrer ce problème et d’autres encore se font encore et toujours attendre.

Le problème de sécurité Heartbleed avait choqué le monde internet plus tôt cette année avec des images quasiment apocalyptiques de vol de données d’utilisateurs. De messages qui circulaient, il apparaissait en tout cas que bien peu de moyens (financiers) étaient consacrés au développement et à la maintenance d’éléments parfois extrêmement cruciaux d’internet, comme les bibliothèques de codes logiciels utilisées partout.

Encore et toujours un problème d’argent

Lors du récent événement Black Hat, l’on a expliqué quelles étaient les bibliothèques utilisées à grande échelle, combien elles souffraient de problèmes sécuritaires et comment elles étaient supportées.

Il en ressortait entre autres que malgré les promesses financières, la bibliothèque OpenSSL, qui était à la base du problème Heartbleed, ne dispose encore et toujours que de peu de moyens, notamment dans l’optique d’une sécurité optimale. C’est ainsi que l’on a calculé qu’il faut au minimum six collaborateurs à temps plein pour assurer un support correct, alors que les moyens collectés ne permettaient que d’engager deux développeurs à temps plein.

Un autre cas problématique concernait la bibliothèque FreeType utilisée dans plus d’un milliard d’appareils (iOS, Android, ChromeOS, Ghostscript – un interpréteur Postscript dans les imprimantes). Or ces dernières années, l’on a repéré plus de 50 points faibles dans FreeType, offrant entre autres des possibilités de prise de contrôle de smartphones (iPhone), d’attaques ‘déni de service’, etc.

Des problèmes de sécurité se manifestent aussi dans les structures de développement logiciel et ce, même si ici, davantage de personnes y collaborent souvent.

Responsabilité

Dans un débat consacré à la présentation à Black Hat, il a été dit entre autres que les développeurs de software – tant commerciaux qu’en entreprises – ne consacrent trop souvent aucune attention aux qualités sécuritaires des bibliothèques ou structures (frameworks) ou ignorent comment utiliser ces moyens de manière sûre. Souvent, les patches sécuritaires ne sont pas suivis dans les bibliothèques et structures et ne sont exécutés qu’avec les nouvelles versions des logiciels.

Dans le débat, des voix se sont fait aussi entendre pour rendre les producteurs de software responsables des problèmes de sécurité dans leurs logiciels et éventuellement pour les obliger à payer les dommages causés par ce genre de lacunes. Comme cette suggestion allait à coup sûr se heurter à une forte résistance de la part de l’industrie du software, l’on a aussi passé en revue les mesures possibles que les personnes qui achètent ou font développer des logiciels, peuvent prendre. C’est ainsi qu’elles pourraient éventuellement exiger que le software d’un tiers soit audité au niveau de sa sécurité. Ou elles pourraient de leur propre initiative faire insérer dans les contrats des clauses de responsabilité, comme cela est entre autres stipulé dans l’OWASP Secure Software Contract Annex – et qualifié de vivement recommandé.

Vous avez repéré une erreur ou disposez de plus d’infos? Signalez-le ici

Contenu partenaire