Et si OpenSSL était l'incontournable bible de la sécurité informatique ?
A l'image de la monoculture Windows sur les PC, analyse d'un expert

Le , par Arsene Newman, Expert éminent sénior
Et si Heartbleed avait affecté les systèmes d'exploitation Microsoft, qui dominent largement le marché des ordinateurs ? Quelles auraient été les conséquences d'une telle faille ? C'est la question posée par Dan Geer directeur de la sécurité informatique de In-Q-Tel.

Pour rappel, le règne de Windows au cours des dernières années a démontré qu'une monoculture n'est pas sans danger et la découverte d'une faille n'implique pas la fin de son exploitation, car cela demande beaucoup d'efforts et de moyens pour fixer toutes les machines affectées.

Geer estime que Heartbleed est symptomatique des larges problèmes rencontrés au cours de l'ère post-Windows actuelle : ère où les entreprises comptent sur différents équipements et logiciels, même si de légers bugs de ces derniers (non critiques) peuvent perturber grandement le fonctionnement d'une entreprise.

Pour celui-ci, « Heartbleed est instructif », même si « son déploiement n'est pas suffisamment large pour parler de monoculture à l'échelle d'Internet, la faille a un coût très substantiel ».

Alors, si OpenSSL était la bible des bibliothèques de sécurité, cela pourrait créer des conditions idéales pour l'apparition d'une faille logicielle dite « de mode commun », où différents systèmes se baseraient sur un élément défaillant commun (un élément matériel ou logiciel), ce qui aurait des conséquences désastreuses.

« Internet, en tant que tel, a été conçu de manière à résister à des pannes aléatoires, il n'a pas été conçu pour résister à des pannes bien ciblées », a déclaré Geer, avant de rajouter que « La faille Heartbleed peut être imputée à la complexité : toutes les normes de l'Internet ont été étendues avec des options compliquées qu'aucune personne ne connaît vraiment. De même, elle peut être imputée à l'insuffisance des investissements : la relecture du code open source est rarement financée et dans le cas contraire jamais durablement. Enfin, elle est à attribuer à la mauvaise planification : des déploiements à grande échelle comportant des fonctions critiques, mais sans aucun mécanisme de correction des failles ».

Mais alors quelle est la solution ? Pour Geer, cela ressemble à 3 approches différentes : tout d'abord multiplier la coopération entre les différents acteurs d'Internet (privé/public, open source/propriétaire) pour améliorer la sécurité et détecter les éventuelles failles de sécurité de certains éléments de base largement utilisés sur Internet, ou encore faire la chasse aux bugs en appliquant des politiques très strictes dans le développement logiciel pour limiter leurs apparitions en amont, enfin la troisième et dernière solution envisagée serait de développer des systèmes en mesure de fixer automatiquement leurs failles, systèmes qui seront issus d'un domaine en plein essor, l'informatique autonome (Autonomic computing).

Source : Billet de blog de Dan Geer

Et vous ?

Qu’en pensez-vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de abriotde abriotde - Membre éprouvé https://www.developpez.com
le 28/04/2014 à 22:57
Tout système est susceptible d'avoir des failles et il est prouvé que l'Open-Source est de ce point de vue très sur. Tout informaticien sait qu'un système sûre est un système à jour. Il existe aujourd'hui des moyens simple de mettre a jour ses logiciels d'une ligne de commande dans le monde de l'Open-Source. Mais surtout le logiciel propriétaire n'a pas intérêt a faire connaitre que son logiciel a une faille (Apple est expert dans ce domaine) et donc n'incite pas a une mise a jour (qui est d'ailleurs souvent payante, c'est pourquoi les entreprises sont réticente a faire évoluer leur parc fonctionnel et stable (cf Windows XP)). Ainsi si l'éditeur de logiciel a corrigé une faille, elle mettra longtemps a être diffusé, ce n'est pas le cas de l'Open-Source.
Le point faible de l'Open-Source, c'est le temps de mise a jour des librairies qu'utilise un logiciel compte tenu de manque de moyen. Mais c'est surtout vrai sur les petits logiciel avec une petites communauté Open-Source. Aujourd'hui Linux, Apache, PHP, OpenDNS sont les logiciels dominant internet et ils sont Open-Sources. Il est très difficile de les prendre en défaut car ils ont de grosses communauté a l’affût des failles. Ils sont a la base de Google, Oracle, Facebook, eBay... alors ils ont les moyens.
Avatar de Simara1170 Simara1170 - Membre éprouvé https://www.developpez.com
le 29/04/2014 à 9:40
Pourquoi on a viré sur un débat Libre/MS?
Pour revenir en arrière
quota approximative:
Si microsoft avait 3 fois une erreur comme ça, il aurait déjà fermé
:
-Windows 95?
-Windows Millenium?
-Windows Vista?
-Windows 8?

Tiens, j'suis à 4, et j'ai pas compté les failles trouvé sur les OS réputés solides de chez MS, la faille dans les fichiers de police sur Xp, c'était quand même bien mignon...
Et puis l'AV de Microsoft, une seule solution -> clic droit -> supprimer, ce truc est une vraie passoire, et passe juste en standard sur ta bécane OEM pour te forcer l'achat d'une suite logicielle entièrement MS. Puis c'est pas comme si MS avait contourné la loi avec Windows 8:
On ne peut plus tatouer les disque durs? Bah c'pas grave, aller on tatoue la CM (secure boot toussa toussa)

Faut arrêter de taper sur OpenSSL parce qu'il y a eu une faille. Y'a eu une merde dans un code open source? Et après? Y'en a jamais eu dans du code proprio? J'aurais tendance à dire qu'il y en a plus: ton code est fermé, alors tu peux programmer comme un gros sale, tu t'en fout, personne pourras le lire, et si un bug est remonté, tu t'en bat le zob tout autant, puisque t'auras déjà fait ton CA dessus, regarde avec Win8: "Vous voulez le retour du bouton démarrer? Ca feras 200€, parce que ça sera sur Win9" (perso, j'ai classic shell et ça m'a coûté 2 minutes de mon temps pour l'installer et le paramétrer...)

Bref, met la faille en regard d'un autre problème bien connu: le bug de l'an 2000: bawi tout est parti en vacances parce qu'on avait pas jugé utile de coder la date sur 4 chiffres...

Il y a eu une faille importante, et il y en aura d'autres à venir...

Petite aparté, sur les DDOS: il est quasiment impossible de se prémunir d'une attaque DDOS bien menée... Et puis une DDOS, c'est pas automatisée? Petite astuce, tape LOIC anonymous sur le Gogole, j'suis sûr que tu trouveras un petit programme adapté dans le cas d'attaque communautaire, et pour les pc zombies, c'est vrai que je vois bien le hacker se faire chier à véroler un par un ses 10k zombies...
Avatar de TheGreyMustache TheGreyMustache - Membre du Club https://www.developpez.com
le 30/04/2014 à 19:40
Entre le vrai risque et la grosse farce, mon coeur hésite un peu. Concernant le codage des dates auquel tu fais allusion, il ne faut pas oublier que nombre de systèmes avaient été conçus à une époque que tu n'as peut être pas connue, quand la mémoire et le stockage étaient limités. Cela n'a rien à voir avec le sujet en cours... me concernant, dans les années 80, on utilisait des logiciels qui codaient l'année sur 1 caractère. Cela était volontaire et pas un bug comme le soit disant bug de l'an 2000.
Avatar de Simara1170 Simara1170 - Membre éprouvé https://www.developpez.com
le 01/05/2014 à 10:31
Là, en l'occurence, je faisais référence à une société d'assurance en Suisse qui stocke sur AS400 depuis des lustres (puisque ça continue encore) avec des bandes journalière etc, bref la mémoire était pas franchement un souci pour eux, et pourtant quand les dev' ont fait remonté que le passage à l'an 2000 pourrait être source de bug, le chef de service en poste ne les avait pas cru... Résultat, toutes les applications sont partis en carafe, et la dev' team s'est tapé des journées de 15h pour remettre ça d'aplomb... Ca fait bien d'être appelé à une heure du matin le 1er janvier, quand t'es un poil bourré et qu'on te dit, faut aller bosser y'a plus rien qui marche...
Le bug de l'an 2000 en est un sans en être un: il y a des soucis parce que les dev' se disaient "mon appli sera redéveloppée dans les 5 ans de toutes façon..." C'est le provisoire qui a dure qui a tout envoyé péter... Enfin, remarque aujourd'hui, rien de nouveau sous le soleil, le provisoire qui dure en informatique, c'est la base du métier pour certains -_-'
Avatar de Pierre GIRARD Pierre GIRARD - Expert éminent https://www.developpez.com
le 01/05/2014 à 12:28
Personnellement, j'ai vécu ce "Bug de l'an 2000" en astreinte, comme pratiquement tout le service. En fin de compte, il ne s'est rien passé pour nous (sur des applications et serveur UNIX). Mais, dès le lendemain, on a quand même appris que des problèmes avaient existé ailleurs.

Par contre, les services développement travaillaient sur ce problème depuis plus d'un an et étaient sensés avoir par avance résolu tous les problèmes potentiels.

Donc :
  1. Le bug de l'an 2000 n'était pas une farce.
  2. Ceux qui ont devancé le problème suffisamment à l'avance n'ont pas eu de bug.


Et d'ailleurs, le même arsenal préventif a été déployé quelques temps plus tard pour le passage à l'Euro.

C'est même grâce à ça qu'une prestation de service est passé de 6 mois à 18 mois, puis ... finalement et de fil en aiguille à 7 ans.
Avatar de Simara1170 Simara1170 - Membre éprouvé https://www.developpez.com
le 02/05/2014 à 10:20
7 pour passer du franc à l'euro, gg pour la procrastination
Avatar de Pierre GIRARD Pierre GIRARD - Expert éminent https://www.developpez.com
le 02/05/2014 à 11:13
Pas 7 ans pour l'Euro, mais arrivé dans la place pour des déménagements de serveurs, ça s'est prolongé par le passage à l'an 2000 ... puis le passage à l'Euro ... puis, ils étaient tellement habitués à moi que de 6 mois en 6 mois, je suis resté dans le service un peu plus de 7 ans.
Avatar de tulipebleu tulipebleu - Membre régulier https://www.developpez.com
le 03/05/2014 à 12:07
Bonjour,

Est-ce que quelqu'un a trouvé quel est la couverture de code des tests de OpenSSL ?

Je ne l'ai pas trouvé sur le site officiel : https://www.openssl.org/

Se serait intéressant pour comprendre si ce problème aurait pu être détecté.
Avatar de tomlev tomlev - Rédacteur/Modérateur https://www.developpez.com
le 03/05/2014 à 12:29
Citation Envoyé par tulipebleu Voir le message
Bonjour,

Est-ce que quelqu'un a trouvé quel est la couverture de code des tests de OpenSSL ?

Je ne l'ai pas trouvé sur le site officiel : https://www.openssl.org/

Se serait intéressant pour comprendre si ce problème aurait pu être détecté.
La couverture de code est une métrique utile, mais pas suffisante. Ca vérifie seulement que tous les chemins de code ont été exécutées lors des tests, mais ce n'est pas parce que 100% du code est couvert qu'il n'y a pas de bugs. En l'occurrence, si j'ai bien compris la fonction qui pose problème oublie de vérifier la longueur demandée avant d'appeler memcpy : s'il n'y a pas de condition qui vérifie la longueur, il n'y a qu'un chemin de code quelle que soit la longueur demandée, donc la couverture de code ne peut pas détecter ce problème.
Avatar de Arsene Newman Arsene Newman - Expert éminent sénior https://www.developpez.com
le 01/06/2014 à 14:58
Le consortium CII finance deux développeurs et un audit pour sécuriser OpenSSL
5,4 millions de dollars alloués au financement de projets open source critiques

Plus d’un mois après l’annonce de la création du consortium CII (Core Infrastructure Initiative) en réponse au tollé provoqué par la faille d’OpenSSL Heartbleed, une feuille de route a été émise. Le but de la manœuvre est de financer certains projets libres pour les auditer ainsi que détecter et corriger leurs bugs.

Dirigé par la fondation Linux et réunissant différents géants de l’IT y compris ceux qui sont traditionnellement adeptes des logiciels propriétaires comme Microsoft, le consortium a décidé de financer en priorité le projet OpenSSL en affectant deux développeurs et en finançant un audit qui se fera via OCAP (Open Crypto Audit Project).

Outre OpenSSL, la CII a aussi décidé du financement de deux autres projets : OpenSSH et le protocole NTP (Network Time Protocol). Un conseil consultatif a été également créé pour aider les sociétés participantes aux projets open source, qui ont besoin de support.

« Tout développement logiciel nécessite un support et un financement. Le logiciel open source ne fait pas exception et mérite une attention à hauteur du rôle dominant qu’il joue aujourd’hui dans le support mondial des infrastructures de l’information » a expliqué Jim Zemlin, Directeur exécutif de la fondation Linux, avant de rajouter : « La CII met en œuvre la même approche collaborative qui est utilisée pour le développement logiciel que pour le financement des projets les plus critiques. L’objectif de la CII est de passer d’une réponse réactive à la crise à une approche proactive afin d’identifier et de financer les projets qui sont le plus dans le besoin. Je suis ravi que nous ayons maintenant un forum pour connecter ceux dans le besoin avec ceux disposant des fonds ».

Enfin, la fondation Linux a annoncé que plus de 5.4 millions de dollars ont d’ores et déjà été alloués et que le consortium a été rejoint par d’autres acteurs majeurs de l’IT. Il s’agit notamment d’Adobe, Bloomberg, HP, Huawei et Salesforce.

Source : Annonce Linux Foundation

Et vous ?

Pensez-vous que ce financement sera suffisant pour éviter un nouvel heartbleed ?
Contacter le responsable de la rubrique Accueil