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.
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
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.Envoyé par Colmea
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
C'est assez vrai
OpenSSL : 300 000 serveurs encore vulnérables à Heartbleed
certains administrateurs ne prennent pas la peine d’appliquer des correctifs
Suite à l’annonce de Heartbleed dans OpenSSL, les sites Web, applications et autres plateformes ont appliqué en urgence des correctifs pour cette faille importante qui permettait d'accéder aux données sécurisées par TLS/SSL.
Cependant, deux mois après la découverte de la faille, de nombreux serveurs sont encore vulnérables à cette faille. Selon un récent rapport publié par le cabinet de sécurité Errata Security, près de 300 000 serveurs exécutent encore une version d’OpenSSL non corrigée.
Errata Security a pu identifier les serveurs encore vulnérables à OpenSSL en scannant simplement le port 443 couramment utilisé sur le Web pour les connexions HTTP.
Suite à cette analyse, Errata Security constate qu’au fil des mois, les administrateurs ont arrêté d’appliquer les correctifs de sécurité. À la découverte de Heartbleed, la firme de sécurité avait constaté que 600 000 systèmes étaient vulnérables. La moitié de ces serveurs ont été corrigés un mois après (il y avait encore environ 300 000 serveurs vulnérables suite au scan d’Errata Security).
Ce constat préoccupant révèle une situation assez fréquente dans l’industrie IT. L’application des correctifs des failles de sécurité n’est pas immédiate par les administrateurs. « Même dans une dizaine d’années, je m’attends toujours à trouver des milliers de systèmes encore vulnérables », demeure sceptique Errata Security.
Alors que Heartbleed, qui a été beaucoup médiatisée, n’a pas encore été corrigée par certains administrateurs, des correctifs pour sept autres vulnérabilités, dont l’une étiquetée comme critique, ont été publiés en début de ce mois.
Compte tenu du peu de tapage médique autour de ces autres vulnérabilités, ces correctifs pourraient être appliqués par un nombre encore plus faible de plateformes Web.
Source : Errata Security
Et vous ?
Qu'en pensez-vous ?
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
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.
Je ne pense pas qu'il soit question de tapage médiatique, c'est une constance quand on aborde les notions de sécurité, généralement quand on fait une estimation du risque c'est une certaine considération plus tangible qui l'emporte. pour certains (et DSI) l'esquive est un sport très apprécié.
Et combien de routeurs et d'autre périphériques nécessitant une mise à jour manuelle ?300 000 serveurs encore vulnérables à Heartbleed
bravo
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.
Je suis d'accord avec toi pour ce qui est d'éviter les sites vulnérables et encore moins les achats en ligne. Et pour ta question, tu peux essayer Lastpass, c'est une application qui s'intègre à Firefox, Chrome, Android...Elle protège tes comptes et mots de passe en ligne, elle est étanche au bug heartbleed et elle t'avise si un de tes mots de passe est touché par heartbleed.
Frederiks,
Répondre avec citation
Partager