En tant que Français de l'étranger, j'ai aujourd'hui reçu mon mot de passe pour voter aux législatives par Internet.
Je n'ai rien demandé, c'est une opportunité supplémentaire de forcer un peu la main aux électeurs qui risqueraient d'encombrer inutilement les bureaux de vote.
Mais pour que cette méthode prenne toute sa valeur, il faut que la sécurité aille au-delà de la norme, au-delà de la sécurisation de l'adresse IP de Mme Albanel.
Il faut du lourd!
C'est pourquoi le mot (…)
Lu sur LWN :
“We wouldn’t share this with Google for even $1 million,” says [Vupen's Chaouki] Bekrar. “We don’t want to give them any knowledge that can help them in fixing this exploit or other similar exploits. We want to keep this for our customers.”
Those customers, after all, don’t aim to fix Google’s security bugs or those of any other commercial software vendor. They’re government agencies who purchase such “zero-day” exploits, or hacking techniques that use undisclosed flaws (…)
Il y a quelques mois était publiée la version 5.3.7 de PHP, sans s'assurer que certains bugs critiques, comme celui de la fonction crypt(), avaient été corrigés.
Cela avait conduit a une sortie précipitée de PHP 5.3.8 contenant les correctifs nécessaires avec une alerte pour la version 5.3.7 .
Beaucoup ont alors espéré que les développeurs de PHP allaient changer de méthodes de travail.
Le 10 janvier sortait la version 5.3.9 de PHP qui contenait, entre autres, un correctif pour une vieille faille de sécurité qui permettait de fabriquer facilement des collisions dans une hashtable conduisant à un déni de service (faille déjà mentionnée ici-même).
Le hic fut que le correctif introduisait une nouvelle faille de sécurité qui, pour éviter de permettre de faire des collisions, permettait une exécution arbitraire de code.
Le 2 février fut publié la version 5.3.10, qui corrige la faille introduite par le correctif précédent.
Une faille de sécurité dans le protocole SSL 3.0 (et inférieur) et TLS 1.0 a été découverte. Ces protocoles garantissent l’accès chiffré aux serveurs Web. Il n’y a donc plus aucun site Web qui est à l’abri d’une attaque « man in the middle ».
Concrètement, l’attaque consiste à injecter du texte connu dans une page Web (via du JavaScript introduit dans une publicité vérolée, par exemple). Après, il suffit d’écouter la conversion (il faut quand même une session de 30 minutes pour l’exploit actuel) pour découvrir la clef AES. L’exploit permet donc de déchiffrer la page, mais aussi les cookies, et donc de s’identifier sur le site visé.
La faille concerne la version 1.0 de TLS et est corrigée dans la version 1.1, sortie en 2006. En outre, OpenSSL propose un contournement depuis 2004 ; il consiste à injecter des données aléatoires dans la transaction. Malheureusement, les navigateurs utilisent principalement NSS plutôt qu’OpenSSL, et même si sur le serveur on peut forcer l’utilisation de TLS 1.1 ou 1.2, très peu de navigateurs Web les supportent, ce qui freine le déploiement sur les serveurs. Actuellement, seuls IE 9 et Opera en sont capables !
Il faut cependant noter que ces failles sont connues depuis longtemps, c’est ce qui avait mené au correctif dans OpenSSL et à la création de TLS 1.1. Mais c’est la première fois qu’une attaque est publiée, validant ces propositions.
Quelques conseils de navigation :
Merci à Altor pour son aide lors de la rédaction de cette dépêche.
Cher journal,
Je t'ecris aujourd'hui en cette belle journee de vendredi pour t'annoncer que le fameux bug DOS de apache (concernant le support de range cf https://linuxfr.org/users/spack/journaux/apache-nappr%C3%A9cie-pas-le-http-range ) parait enfin etre corrige.
Pour rappel, ce bug concernait l'ensemble des version apache (1 et 2) et permettait en theorie de DOSer un serveur avec un simple heade
r http.
Changelog de la version 2.2.20 : http://www.apache.org/dist/httpd/CHANGES_2.2.20
Telecharger cette nouvelle version: http://httpd.apache.org/download.cgi#apache22
