7 pour passer du franc à l'euro, gg pour la procrastination
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
7 pour passer du franc à l'euro, gg pour la procrastination
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.
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.Envoyé par tulipebleu
Pas de questions techniques par MP ! Le forum est là pour ça...
Tutoriels : Les nouveautés de C# 6 - Accès aux données avec Dapper - Extraction de données de pages web à l'aide de HTML Agility Pack - La sérialisation XML avec .NET (Aller plus loin) - Les markup extensions en WPF
Le consortium CII finance deux développeurs et un audit pour sécuriser OpenSSL
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 ?
Je ne vois pas en quoi un financement même sans limite pourrait supprimer tous les risques. Par contre, si ça permet de multiplier les contrôles, c'est forcément un plus.
Ça sera toujours mieux qu'un ou deux bénévoles qui font ça quand ils ont le temps le soir.
Les projets comme OpenSSL ne sont plus maintenu par 1 ou 2 bénévoles de temps en temps. Cela fait longtemps que des ingénieurs de Google, Facebook ou encore Microsoft, Apple sont payé pour développer des projets Open-source utilisés en interne. Ce dont il est question c'est de maintenir et auditer les projets très critique de manière "permanente". Actuellement, les ingénieur faisait signe quand il trouvaient un bug ou plus souvent une faille dans le protocole et plus souvent encore une nouvelle fonctionnalité a ajouter et l'ajoutait. Certes toute une communauté vérifiait derrière mais ce n'était pas défini précisément et le vieux code était rarement audité.
Il faut savoir qu'aucune entreprise privé ne maintient un code comme OpenSSH/OpenSSL aussi largement utilisé et critique. Certes certaines entreprise travail pour la défense sur des outils plus sécurisé encore mais le plus souvent ils se basent sur OpenSSH/OpenSSL et si ce n'est pas le cas en reprennent l'essence sur des pojet plus difficile a hacké parce que peu utilisés.
Bonne initiative ! En espérant qu'elle s'élargisse rapidement à d'autres projets.
Par contre, est-ce que c'est bien nécessaire de mettre deux personnes à plein temps sur OpenSSL ? (vraie question, je ne connais pas assez le projet pour juger de l'utilité de deux devs sur ce projet).
La première nécessité : éviter les pertes.
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 cette vidéo 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.
Découverte de sept nouvelles failles de sécurité dans OpenSSL
des correctifs sont disponibles
OpenSSL, la bibliothèque de chiffrement open source largement utilisé sur le Web revient au-devant de la scène après la faille Heartbleed (« cœur qui saigne »), qui avait fait un véritable tollé sur le Web.
Sept nouvelles vulnérabilités ont été découvertes dans la solution, dont l’une étiquetée comme critique, permet d’espionner des communications sécurisées avec TLS/SSL.
Selon le « CVE-2014-0224 » utilisé pour référencer la faille, un pirate pourrait l’exploiter pour effectuer une attaque de type Man-in-the-middle (MITM) et exécuter du code arbitraire pour déchiffrer et modifier les données échangées entre un client et un serveur. Pour réussir une attaque, le pirate devrait donc être en mesure dans un premier temps d’intercepter le trafic entre un client et un serveur.
Toutes les versions du client OpenSSL sont affectées par cette faille. Du côté serveur, seules les versions 1.0.1 et 1.0.2-beta1 sont touchées. La faille avait été signalée aux développeurs du projet le 1er mai par le chercheur japonais Masashi Kikuchi. La faille est divulguée publiquement suite à la sortie des correctifs de sécurité.
Une autre faille a également donné des sueurs froides aux experts en sécurité. Il s’agit de la vulnérabilité référencée par le « CVE-2014-0195 ». Elle concerne le Datagram Transport Layer Security (DTLS) et avait été signalée depuis le 23 avril. L’exploitation réussie de cette faille par l’envoi de fragments DTLS invalides à un client ou un serveur OpenSSL, peut entrainer un dépassement de tampon et ouvrir la voie à l’exécution du code malveillant sur un client ou un serveur vulnérable.
DTLS est également affecté par une vulnérabilité récursive étiquetée « CVE-2014-0221 » et qualifiée de non critique. Un pirate pourrait via une attaque de type Man-in-the-middle, injecter du code récursif qui pourrait aboutir à une attaque par déni de service (DOS).
Deux autres vulnérabilités marquées comme importantes peuvent également entrainer une attaque par déni de service. Les versions 1.0.0 et 1.0.1 d’OpenSSL où « SSL_MODE_RELEASE_BUFFERS » est activé sont affectées par cette faille.
Les développeurs de la bibliothèque de chiffrement ont publié des correctifs pour toutes les failles qui ont été mentionnées dans le bulletin de sécurité. Il est conseillé d’appliquer urgemment les correctifs de sécurité.
Il faut noter que suite à la découverte de la faille Heartbleed, les géants de l’IT à travers le consortium Core Infrastructure Initiative se sont regroupés pour financer les projets open source critiques. OpenSSL sera désormais maintenu par deux développeurs à plein temps et aura droit un audit qui se fera via OCAP (Open Crypto Audit Project).
Source : Le bulletin de sécurité d'OpenSSL
Vous souhaitez participer aux rubriques .NET ? Contactez-moi
Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
Mon blog, Mes articles, Me suivre sur Twitter
En posant correctement votre problème, on trouve la moitié de la solution
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 !
Une façon assez originale de voir la chose...C'est la NSA qui va commencer à faire la tête : leurs portes secrètes sont murées les unes après les autres !
Quand on regarde les choses de cette manière, ça en dit long sur la relation ambigue de la NSA avec l'intérêt du public (y compris du public étasunien)...Une façon assez originale de voir la chose
La sécurité encore à la traine
Ces chiffres montrent clairement à quel point la prise en compte du paramètre sécurité dans les projets web est médiocre.
Lorsque l'on regarde quelques statistiques sur le temps de correction des vulnérabilités sur un site Internet, on voit qu'il faut parfois 6 mois voire un an avant que les failles soient corrigées.
Heartbleed a fait beaucoup de bruit, certaines entreprises en ont même profité pour en faire une campagne marketing, mais au final ça n'aura pas suffit à mobiliser les bonnes personnes : celles qui devraient avoir pour responsabilité la sécurité des données des utilisateurs.
Fonctionnalités, ergonomie et design sont la priorité pour beaucoup d'entreprises, jusqu'au jour où un malheur arrive.
En tant qu'utilisateur, je souhaite éviter les sites encore vulnérables. Par ailleurs, cette forme de protection conduirait à un boycotte de fait, ce qui mettrait un peu de pression sur les firmes pour qu'elles mettent à jour leur librairie. On peut rêver...
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.
C'est de la provocation, mais ...
Tu peux essayer ici:
https://www.trustworthyinternet.org/ssl-pulse/
https://www.ssllabs.com/ssltest/
Mais bon, les vulnérabilités ne sont pas uniquement induites via
l'implémentation d'SSL, certains sites même avec cette couche à jour
peuvent cacher d'autres failles :[
Il me semble même que les outils Mozilla sont capables d'afficher une
boîte d'alerte si les sites posent problèmes.
Répondre avec citation
Partager