Discussion :

[Aiekick]

si l'opensource c'est le mal alors que pensez du closed source surtout depuis qu'on sait que la NSA a installé des backdoor dans moults logiciel closed-source ?

Et au moins une fois la faille réparée on sait de source sure qu'elle est réparée alos que dans les soft closed-source, il peuvent dire ce qu'ils veulent...

[stardeath]

tu te demandes pourquoi des gens te mettent des "moins". alors je vais parler de mon cas:
j'ai déjà lu des masses de messages venant de toi et ça tourne toujours autour du même thême: "l'open-source c'est mal, on peut pas leur faire de procès. Microsoft est une entreprise de dieux vivants". tu dis toujours la même chose, je sais déjà ce que ton message va dire avant de le lire. et une fois arrivé à la fin du message j'ai la déception de me rendre compte que j'ai deviné juste.
je ne veux pas perdre 20 minutes à faire une réponse argumentée que tu ne liras pas, avec des sources que tu ne lira pas non plus. je te mets un "moins", ça va plus vite et c'est pas moins efficace.
j'espère avoir éclairé ta lanterne, mais en même temps, je doute que tu aies lu jusque là...

l'hopital, la charité tout ça, c'est quand même navrant de toujours en revenir au même discours ...

[Invité]

Juniper et Cisco ont sorti leurs bulletins :

http://kb.juniper.net/InfoCenter/ind...nt&id=JSA10623

http://tools.cisco.com/security/cent...409-heartbleed


Je sens que je vais avoir un peu de taf dans les jours qui viennent

Steph

[guillaume07]

en 35 ans de carrière c'est la première fois que je vois pareil bug!

[Invité]

Pas toujours facile de planifier un donwtime pour patcher le(s) équipement(s) impacté(s)...

En attendant, vous pouvez carrément bloquer le heartbeat du handshake TLS avec la règle iptable suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j DROP

Il faudra bien sûr adapter le --dport si ce n'est pas de l'https et vérifier qu'il n'y a pas d'impact fonctionnel sur votre appli... A tester donc évidemment avant toute mise en prod...

Steph

[Algo D.DN]

En cas de besoin concernant les distributions (GNU-Linux), les bulletins de sécurité OpenSSL se trouvent aux adresses respectives ci-dessous:

Bulletin Red Hat: https://rhn.redhat.com/errata/RHSA-2014-0376.html

Bulletin Fedora: https://lwn.net/Articles/594066/

Bulletin OpenSuSe: http://lists.opensuse.org/opensuse-s.../msg00005.html

Bulletin Debian: http://www.debian.org/security/2014/dsa-2896

Bulletin FreeBSD: http://www.freebsd.org/security/advi...06.openssl.asc

[Pierre GIRARD]

Au niveau local, si quelqu'un réussi à se connecter sur mon PC et qu'il arrive à récupérer des mots de passes ??? je ne vois pas trop l’intérêt, vu qu'il est déjà sur mon PC.

Et, Je ne sais pas pour les autres, mais que peut-on faire si sa banque (par exemple) est victime du bug et que quelqu'un y pirate ses coordonnées bancaires ?

A part faire peur ...? Mais bon, la peur organisée, j'ai déjà connu ça, ça s'appelait : Le "Bug de l'an 2000"

[forthx]

Au niveau local, si quelqu'un réussi à se connecter sur mon PC et qu'il arrive à récupérer des mots de passes ??? je ne vois pas trop l’intérêt, vu qu'il est déjà sur mon PC.

On peu se connecter a un pc sans pouvoir tout faire.
En fait c'est surtout valable si ton pc n'offre pas de service externe, ou que tu a un routeur qui bloque la communication de ces services avec l'exterieur. Si ton pc offre une connexion ssh, ou fait du service web https ET que tu utilise pour ces services openSSL (Ca fait beaucoup de si mais on est probablement plusieurs ici dans ce cas de figure), alors ta machine cours un risque si tu ne fait rien.

[Pierre GIRARD]

Je ne risque rien dans mon cas, mais la question était : que risque-t-on exactement si on correspond à ces critères ? A part que quelqu'un puisse lire mon courrier ou accède à mes factures ou à mes déclarations d’impôts ? Et que ferait-on de tout ça ?

[Arsene Newman]

Et si OpenSSL était l'incontournable bible de la sécurité ?
A l'image de la monoculture Windows au sein du marché des PC, analyse d’un expert

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 ?

[abriotde]

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.

[Simara1170]

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...

[TheGreyMustache]

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.

[Simara1170]

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 -_-'

[Pierre GIRARD]

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.

[Simara1170]

7 pour passer du franc à l'euro, gg pour la procrastination

[Pierre GIRARD]

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.

[tulipebleu]

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é.

[tomlev]

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.

[Arsene Newman]

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 ?