Vu qu’il est possible d’utiliser plus de 140 signes par messages ici, ça sera plus simple que sur Twitter pour détailler un point de vue sur cette affaire.
Le cœur du problème reste une vulnérabilité introduite il y a un peu plus de 3 ans dans la source-tree Java 7 et signalée à Oracle en avril dernier. En juin dernier, le patchset cumulatif d’Oracle pour Java fixe d’autres vulnérabilités mais pas celle-là. On est donc 4 mois après le signalement de la vulnérabilité sans aucun patch, cela peut être choquant pour certains mais d’autres font bien pire.
Le problème c’est que dans le cas présent, des attaques (ciblées ou pas mais ce n’est pas la question) exploitent la vulnérabilité. La mécanique inhérente à tout 0-day s’est donc mise en place : FireEye premier à détecter l’attaque en fait profiter les autres, les spécialistes de la sécurité offensives sortent leur PoC, les CERT mettent en garde les utilisateurs et tout le monde attend un patch qui n’est arrivé qu’hier soir.
On peut s’émouvoir de la rapidité avec laquelle la communauté a réagi mais si on y réfléchi, c’est logique : la vulnérabilité est intéressante et simple à exploiter (concerne 3/4 des machines connectées à l’internet, non-patchée, agnostique vis à vis de l’OS, exploitable sans avoir à bypasser l’ASLR & cie). On aurait aussi pu croire que l’aspect opensource de Java 7 aurait permit un patch indépendant de celui du vendeur mais a priori personne ne l’a fait, le peu d’implication de la communauté dans le management par Oracle de ses projets OpenSource ne doit y être étranger.
Par contre, il paraitrait que ce comportement est irresponsable et qu’on aurait du éviter d’informer le grand public de l’existence d’une telle vulnérabilité pour mieux les protéger, c’est en substance le propos du chef de la division de lutte contre la cybercriminalité de notre chère gendarmerie nationale (qui semble par ailleurs ne pas être assujetti au devoir de réserve comme l’ensemble des ses collègues) sur twitter et son blog. Si on passe sous silence l’aspect bolchevique du traitement de l’information que ce propos induit, on peut s’amuser à réfléchir deux minutes aux conséquences d’un tel comportement :
– l’absence de documentation fiable et accessible sur la vulnérabilité empêcherait la plupart des cibles d’attaques de s’en protéger. Seuls ceux qui payent au prix fort les appliances de la société connaissant la faille serait protégés.
– certains puissants pourraient abuser de la vulnérabilité dans leurs intérêts (exemple des 0-day de Duqu et Flame)
– le vendeur à l’origine de la vulnérabilité n’aurait aucune raison de se presser à patcher car d’un côté il aurait des utilisateurs qui ne se plaignent pas et de l’autre des personnes au courant de la faille mais dont l’intérêt serait de conserver l’exclusivité de la connaissance de la faille
On ne peut nier qu’entre de mauvaises mains, la connaissance d’une telle faille induit des risques accrus mais il est suicidaire de baser la sécurité des systèmes d’information uniquement sur le fait que l’attaquant n’aura pas eu vent d’une information ou d’une autre.
majinboo.42
Afin de soutenir l’initiative du 42Registry, ce blog est désormais aussi accessible via l’URL http://majinboo.42/. L’extension .42 n’étant pas une extension officielle de l’ICANN, il faut utiliser un resolver avec une configuration spécifique (cf le site du 42Registry)
L’initiative est intéressante pour deux raisons :
- L’ICANN a tendance à oublier la neutralité du réseau dans certaines des ses actions (par exemple : l’invalidation de certains noms de domaines sur de simples présomptions), l’émergence de modèles alternatifs à l’ICANN est donc important pour le bon fonctionnement d’un Internet libre et ouvert
- C’est le premier TLD numérique, les RFC ne l’excluent pas mais certains développeurs n’ont jamais eu l’occasion de tester le bon fonctionnement de leur code avec ce type de domaines.
En particulier les développeurs de Lighttpd qui ont eu la bonne idée d’inclure un parsing supplémentaire pour le header Host de chaque requête HTTP traitée. Cette fonctionnalité n’est a priori pas nécessaire pour respecter les RFC et n’apporte pas grand chose d’un point de vue sécurité (si le parsing générique des headers HTTP contient une vulnérabilité, ce parsing ne protégera qu’un seul header et ne bloquera pas l’exploitation sur les autres headers). Par contre ce parsing renvoi une erreur sur TLD numériques : le parseur se prend les pieds dans le tapis quand il parse en commençant par les derniers caractères majinboo.42, il pense qu’il parse une IP alors qu’il est en train de parser un FQDN.
Comme je suis d’une humeur fainéante aujourd’hui et que je ne voyais pas l’intérêt de ce parsing, je me suis limité à un patch désactivant ce parsing. Voici donc le patch quick’n'dirty à déposer dans files/src-request.c si vous utilisez le port FreeBSD :
--- src/request.c.orig 2010-12-28 14:44:38.000000000 +0100
+++ src/request.c 2010-12-28 14:45:30.000000000 +0100
@@ -1102,23 +1102,23 @@
}
/* check hostname field if it is set */
- if (NULL != con->request.http_host &&
- 0 != request_check_hostname(srv, con, con->request.http_host)) {
-
- if (srv->srvconf.log_request_header_on_error) {
- log_error_write(srv, __FILE__, __LINE__, "s",
- "Invalid Hostname -> 400");
- log_error_write(srv, __FILE__, __LINE__, "Sb",
- "request-header:\n",
- con->request.request);
- }
-
- con->http_status = 400;
- con->response.keep_alive = 0;
- con->keep_alive = 0;
-
- return 0;
- }
+// if (NULL != con->request.http_host &&
+// 0 != request_check_hostname(srv, con, con->request.http_host)) {
+//
+// if (srv->srvconf.log_request_header_on_error) {
+// log_error_write(srv, __FILE__, __LINE__, "s",
+// "Invalid Hostname -> 400");
+// log_error_write(srv, __FILE__, __LINE__, "Sb",
+// "request-header:\n",
+// con->request.request);
+// }
+//
+// con->http_status = 400;
+// con->response.keep_alive = 0;
+// con->keep_alive = 0;
+//
+// return 0;
+// }
switch(con->request.http_method) {
case HTTP_METHOD_GET:
Un NAS sous FreeBSD : deuxième partie
Je viens de publier la deuxième partie de la série d’article sur la conception d’un NAS sous FreeBSD : au menu, l’installation du matériel et le paramétrage de ZFS. Au passage, je vous fait profiter de mon gros coup de gueule sur Materiel.net qui met un mois à livrer du matériel annoncé comme livré avec un délai de 2/3 jours. Cerise, sur le gateau, même avec un mois de retard, ils livrent un boitier incomplet, j’ai donc attendu 10 jours de plus afin d’avoir ma commande. Je vous recommanderai donc les gars de Mini-ITX.com sont spécialisés dans ce type de boitiers et beaucoup plus sérieux. Le pire c’est qu’ils ne sont pas plus cher et livrent plus rapidement que Materiel.net alors qu’ils sont situés au Royaume-Uni.
Un filer sous FreeBSD : première partie
Je viens de publier la première partie d’une série d’articles qui décriront pas à pas la mise en place d’un filer (serveur de fichier) sous FreeBSD. Le premier article présente les contraintes du projet et explique les différents choix effectués au niveau du matériel. D’autres articles suivront d’ici quelques jours/semaines.
Big Brother is making your web unsecure
Ce qu’il y a de plus effrayant avec certaines grandes entreprises, c’est cette petite manie qu’elles ont de se croire au dessus des règles. Prenons l’exemple de Google, comme toute les grosses boites dans le domaine de l’informatique, ils ont leur équipe « sécurité informatique ». Chez eux, ils font dans l’originalité et appellent cette équipe : la « Google Security Team ». Comme dans toutes les équipes du même genre, on y trouve des chercheurs dans différents domaines. Comme Google est une boite jouissant d’une certaine réputation, ils n’ont pas de mal à recruter des profils intéressants ayant envie d’ajouter une ligne qui peut rapporter gros à leur CV. L’équipe finit donc par monter en compétence et publie donc des vulnérabilités.
Et c’est là que les problèmes commencent. Pas pour Google, ce sont de grand enfants, ils savent quand ils vont publier, ils savent donc quand patcher leurs serveurs. Par contre, ils oublient que reveler une faille un jeudi soir [1] et juste quelques heures après que le patch ait été ajouté dans les sources Linux, c’est rendre l’ensemble des serveurs Linux vulnérable pour au moins un week-end. Et ça n’a pas manqué aucune distribution majeure n’a eu de patch prêt avant lundi.
Jusqu’à hier, on avait donc quasiment l’ensemble des Linux du monde vulnérable et avec comme seule solution de patchage des grosses bidouilles. C’est quand même assez genant, et cela est totalement opposé aux règles communement admises pour la révalation de failles de sécurité. [2]
Trouver une alternative à BIND pour un DNS autoritaire n’est pas chose aisée, entre les usines à gaz comme PowerDNS et les serveur à la licence douteuse comme djbdns, il se dégage quand même NSD. Le challenger accepte les fichiers de zone au format BIND, équipe déjà 3 des root servers, et implémente des fonctionalités avancées comme DNSSEC et IPV6. Il reste cependant limité à une utilisation en tant que NS autoritaire car il ne sait pas effectuer de resolutions récursives.
Comme d’habitude, nous allons commencer par une installation du logiciel par les ports FreeBSD
# cd /usr/ports/dns/nsd # make install clean
Nous allons continuer avec l’édition du fichier de configuration
# cd /usr/local/etc/nsd/ # cp nsd.conf.sample nsd.conf # chmod +w nsd.conf # vi nsd.conf
Le fichier par défaut est relativement bien commenté, j’ai personnellement modifié les lignes suivantes pour avoir un serveur qui n’écoute que sur une des IPs de la box avec un pidfile dans un dossier particulier et j’en ai profité pour ajouter une zone DNS :
ip-address: 213.251.171.146 pidfile: "/var/run/nsd/nsd.pid"
zone: name: "majinboo.org" zonefile: "majinboo.org.zone" outgoing-interface: 213.251.171.146 notify: 217.174.206.169 NOKEY provide-xfr: 217.174.206.169 NOKEY
La modification du chemin du pidfile m’a permis de bypasser un bug lors du lancement du démon, il ne faut pas oublier de créer le dossier en question et d’y donner les droits à l’utilisateur bind.
Avant de lancer le démon, il ne reste plus qu’à créer un fichier de zone au format bind, de le compiler en utilisant zonec et d’ajouter nsd_enable= »YES » à la fin du /etc/rc.conf.
Il est possible d’aller plus loin, par exemple en ajouter des clef DNSSEC pour les échanges entre les serveurs primaires et secondaires.