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 vulnérabilité vient d'être trouvée dans l'utilitaire sudo. Pour rappel, la commande sudo permet à l'administrateur système d'accorder à certains utilisateurs (ou groupes d'utilisateurs) la possibilité de lancer une commande en tant qu'administrateur ou un autre utilisateur. Cette vulnérabilité est présente dans la fonction sudo_debug où un appel à getprogname() est effectué. Or le nom de l’exécutable étant contrôlé par l'utilisateur, il est possible d'induire un comportement non voulu.

Les versions concernées sont les versions 1.8.0 à 1.8.3p1. La version 1.8.3p2 corrige la faille. Apprécions la rapidité de la correction : soumise le 24 janvier dernier au mainteneur de sudo (Todd C. Miller, programmeur OpenBSD), celui-ci propose un patch le 27 janvier et une nouvelle version corrigée le 30 janvier. Soit moins d'une semaine entre la découverte et la version corrigée. Il ne reste plus aux distributions qu'à mettre à jour leurs dépôts pour propager cette correction.

NdM : merci à erdnaxeli pour son journal.

Ceci est une traduction de mon entrée de blog récente. Quelques remarques avant de commencer :

• Mon biais : je travaille chez Mozilla Corporation sur WebGL ;
• le titre original de mon entrée de blog était trop long pour la limite de longueur de titres. Il ne s'agit pas seulement de « Sandboxing » ;
• la traduction est parfois un peu libre, un peu différente de l'original.

D'autre part, comme ici on est chez les Français râleurs, je n'ai pas à prendre autant de pincettes que dans mon blog agrégé sur Planet Mozilla. Donc soyons clairs, ce texte se veut un coup de gueule. Il y a des soi-disant experts en sécurité qui prétendent que Firefox est vulnérable parce qu'il lui manque telle ou telle fonctionnalité présente chez tel concurrent. Sans vouloir nier l'utilité de ces fonctionnalités, j'ai pensé qu'il était temps de remettre les pendules à l'heure : la sécurité des navigateurs est un sujet trop vaste pour qu'une ou deux techniques en particulier puissent faire une grande différence au total, et ces « experts » et autres journalistes se ridiculisent en répétant, sans distance critique, le marketing d'une entreprise… avec laquelle je ne tiens pas à me brouiller, car si je critique son marketing, j'ai souvent eu à travailler avec ses ingénieurs dans les comités de standards, et ça se passe très bien.

Au fil de mon blog, j'ai largement dévié sur un autre sujet qui me tient à cœur : la sécurité de WebGL, qui a elle aussi été victime d'une campagne de dénigrement de la part, cette fois-ci, d'un autre concurrent, qui lui n'a vraiment pas fait dans la dentelle alors qu'ils avaient eux-mêmes une technologie avec les mêmes « failles ».

Sur ce, la traduction de ce blog se trouve en seconde partie

NdM : merci à Benoit Jacob pour son journal.

Les développeurs de Google sont toujours à la recherche de solutions permettant d'améliorer la sécurité du navigateur web Google Chrome (ou son implémentation libre Chromium), ou de leur projet ChromeOS. Dans la dépêche à ce sujet, je vous avais raconté leur participation au projet Capsicum, qui apporte une gestion très fine des privilèges d'un processus, maintenant intégré dans FreeBSD.

Bien que les techniques mises en place par Capsicum soient pensées pour tous les systèmes inspirés d'UNIX, il n'y a pas grand espoir aujourd'hui qu'un port Linux soit accepté par les développeurs noyau ; Capsicum est un projet externe qu'il faudrait d'abord intégrer, ré-exprimer en terme des fonctionnalités existantes dans le noyau ; et les mainteneurs sont notoirement mécontents de la multiplication des solutions de sécurité (les Linux Security Modules en particulier) et ne verraient pas d'un bon œil l'apparition d'un nouveau candidat. Les développeurs Chromium utilisent sous Linux le primitif système de sandboxing seccomp, bien qu'il soit beaucoup moins flexible que Capsicum et donc nettement plus pénible et difficile à utiliser.

Depuis 2009, les développeurs Chrome essaient d'étendre les capacités de seccomp pour mieux répondre à leurs besoins. Les changements se sont révélés beaucoup plus difficiles à faire accepter que prévu : la situation a semblé bloquée à de nombreuses reprises et n'a pas évolué pendant de nombreux mois. Après plusieurs tentatives infructueuses, Will Drewry vient de proposer une nouvelle approche qui pourrait obtenir l'approbation des développeurs noyau ; mais rien n'est encore gagné…

L’équipe de sécurité Debian nous a fait un petit rappel sur leur liste de diffusion au sujet de la fin du support de sécurité pour Debian Lenny, qui se terminera précisément le 6 février 2012.

Après cette date butoir, plus aucune mise à jour de sécurité ou autre correction de bug critique ne sera livrée, c'est dans la logique de fonctionnement du projet Debian.

Voici une traduction de leur annonce datant du 06 décembre 2011 :

Ceci est une notice liée au support de la sécurité sur Debian GNU/Linux 5.0 (nom de code « Lenny ») qui se terminera dans 2 mois.
Le projet Debian a sorti Debian GNU/Linux alias « Squeeze » le 6 Février 2011.
Les utilisateurs et distributeurs ont eu 1 an pour mettre à jour leur version.
Donc, le support lié à la sécurité pour l'ancienne version stable 5.0 se terminera dès le 6 février 2012 comme précédemment annoncé.
Les mises à jours de sécurité pour l’ancienne version stable continuent d’être disponibles sur security.debian.org

Pensez à mettre à jour votre Debian si ce n'est pas déjà fait, ainsi que vos fichiers sources.list.

Quand des chercheurs en informatique font de la théorie, certains écoutent, comme les développeurs de Perl. D'autres dorment au fond de la classe : cette fois, le bonnet d'âne est pour PHP, Python, V8 (JavaScript par Google, qui sert par exemple dans node.js), Ruby (sauf CRuby), de nombreux serveurs d'applications en Java, mais aussi ASP.NET. Ils ont dû se réveiller brutalement mercredi, lors d'une présentation d'Alexander Klink et Julian Wälde au Chaos Communication Congress montrant comment saturer très simplement un serveur grâce à une attaque basée sur la complexité algorithmique.

Les porte-monnaie sont déjà vidés et les dindes attendent patiemment leur sort funeste à côté de ce qui reste de leurs cousins canards/oies. Les images d'un gros monsieur en rouge, avec une barbe digne du geek qui se respecte, se multiplient de façon inquiétante. Bref, Noël est là.

Et comme tous les ans, pile après vient le CCC. Il s'agit de l'évènement organisé par le hackerclub éponyme et qui se nomme Chaos Communication Congress (le 28ème cette année, d'où son nom 28C3). Vous en avez certainement déjà entendu parler, étant donné que des dépêches passent ici-même tous les ans. Alors, vu que je suis très impatiente d'y être, voici un aperçu du programme.

NdM : le CCC met en place des flux audio et vidéo des conférences, et a posteriori les vidéos (par exemple celles de l'année dernière).

Ma société travaille depuis plusieurs mois sur un projet de WAF, ou pare‐feu applicatif, articulé autour du serveur HTTP et proxy inverse nginx. Après une foule de tests et une épreuve du feu pour le moins tendue, la première version stable de NAXSI, c’est son nom, est disponible au téléchargement en code source et en paquet Debian.

NAXSI est sous licence GPL v2 et s’utilise conjointement avec nginx. Son principal but est de bloquer de manière efficace les attaques classiques de type injection SQL, Cross‐Site Scripting, Cross‐Site Request Forgery, ou encore inclusion de sources tierces locales ou distantes.

Au contraire des WAF déjà connus, NAXSI ne se base pas sur des signatures, mais plutôt sur la détection d’attaques connues en interceptant des caractères et autres chaînes suspectes dans les requêtes HTTP. Tel un système anti‐pourriel, NAXSI affecte un score à la requête et, lorsque ce dernier est trop élevé, le client est redirigé sur une page de type 503.

Malgré ses récents faits d’armes, NAXSI reste un projet jeune, et en tant que tel, nécessite plus de tests. Aussi, n’hésitez pas à lui donner sa chance, vos retours seront grandement appréciés !