Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

0PARTAGES

0  0 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Traroth2
Membre chevronné https://www.developpez.com
Le 06/06/2014 à 10:27
Ces 7 failles n'auraient pas été découvertes sans Heartbleed. A quelque chose malheur est bon...

C'est la NSA qui va commencer à faire la tête : leurs portes secrètes sont murées les unes après les autres !
5  0 
Avatar de 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...
5  3 
Avatar de 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.
2  0 
Avatar de 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.
1  0 
Avatar de Jedai
Expert éminent https://www.developpez.com
Le 04/06/2014 à 15:42
Attention : OpenSSH et OpenSSL ne sont pas comparables, ce n'est pas du tout la même équipe et la qualité du code est bien meilleure dans OpenSSH (maintenu par les types d'OpenBSD) que dans OpenSSL (ce qui ne veut pas dire qu'OpenSSH n'a pas de bugs...).

Mettre tant de sous et de moyens dans OpenSSL en l'état me semble une très mauvaise idée, j'aurais préféré que ces moyens soient mis derrière LibreSSL, le fork d'OpenSSL démarré par les types d'OpenBSD et qui a déjà bien nettoyé le code (voir cette page pour des changements détaillés avec commentaires caustiques et pour une présentation du projet et de ses motivations).

A terme, je pense qu'utiliser C pour programmer ce type de bibliothèque est une stratégie erronée et un langage alternatif qui assure un minimum de sécurité par défaut serait un choix préférable.
1  0 
Avatar de Pierre GIRARD
Expert éminent https://www.developpez.com
Le 06/06/2014 à 12:42
Citation Envoyé par Traroth2 Voir le message
...C'est la NSA qui va commencer à faire la tête : leurs portes secrètes sont murées les unes après les autres !
Une façon assez originale de voir la chose
1  0 
Avatar de GTSLASH
Inactif https://www.developpez.com
Le 23/06/2014 à 16:51
300 000 serveurs encore vulnérables à Heartbleed
Et combien de routeurs et d'autre périphériques nécessitant une mise à jour manuelle ?
bravo
1  0 
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 27/06/2014 à 9:54
Citation Envoyé par parrot Voir le message
Existe-t-il des plugins pour navigateurs qui signalent que le site auquel on accède est vulnérable?
ChromeBleed pour chrome, et HeartBleed pour firefox. Je n'utilise pas d'autres navigateurs, mais je suis certain que ca existe.
1  0 
Avatar de 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.
0  0 
Avatar de 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 -_-'
0  0