Il existe un système de miroirs dynamiques sur Internet permettant de visiter un site trop chargé. Il suffit d’ajouter au site visité le suffixe “nyud.net”.
Au hasard, en ces temps d’anxieté nucléaire, le site de la CRIIRAD est accessible ici : http://www.criirad.org.nyud.net/

En ce qui concerne les émanations radioactives, la CRIIRAD nous indique que les gouvernements réalisent un black-out sur les données de mesure déjà réalisées sur le sol américain, canadien, etc. et exige que ces données collectées avec de l’argent public soient fournies au public.

C’est ici : http://www.criirad.org.nyud.net/actualites/dossier2011/japon/11_03_23_Volet1der.pdf

Penchons nous sur un test, avec un oeil orienté “sécurité”, du célèbre CMS spip.
Je teste donc la version 2.1.8. Lors de l’installation, spip m’indique que quelques répertoires doivent offrir au processus “apache” les droits en écriture. Ce n’est pas délirant, dans la mesure où la publication se fait en ligne : je vais y injecter des images, etc.
J’applique donc la règle du “privilège le plus faible” traditionnelle des systèmes de fichiers unix : j’assigne à ces repertoires le groupe apache, et en accordant à ce groupe les droits en écriture :
chgrp www-data IMG/ tmp/ local/ config/
chmod g+w IMG/ tmp/ local/ config/
L’installation terminée, je crée une rubrique, un article, et j’y colle une photo pour voir le résultat.
Le résultat, le voici : une image est bien ajoutée dans le répertoire IMG/ avec les droits en 666.
De nombreux fichiers de spip sont automatiquement passés en droits 666 ou 777, dans les installations par défaut. Y compris des fichiers PHP executés par le serveur web.
Franchement, ça fait peur.
J’ai trouvé une solution simple : remettre un chmod global à une valeur plus saine de manière globale pour spip.
Éditez votre fichier ecrire/mes_options.php, et posez-y le code suivant :
define(‘_SPIP_CHMOD’, 0770);
ou mieux
define(‘_SPIP_CHMOD’, 0570);
Le serveur web aura ainsi les droits de lire les fichiers, et son groupe les droits de lire et modifier ces fichiers.

Je reste tout de même estomaqué de voir un logiciel aussi populaire faire la bêtise monumentale du “chmod 777”, qui est comme chacun le sait réputée pour être la bêtise traditionnelle du newbie.
Pour référence, en sécurité, on ne doit JAMAIS positionner les droits 666 ou 777 sur un fichier, c’est une hérésie, et on a TOUJOURS une meilleure solution. La littérature à ce sujet ne manque pas : commencer par cet article sur la Séparation des privilèges

Et voici la nouvelle crise majeure de sécurité de l’information.
Le FBI est accusé d’avoir fait implanter une ou plusieurs backdoors dans la pile de chiffrement IPSEC d’OpenBSD.
10 années après les faits supposés, le responsable de cette opération se déclare délié de l’accord de confidentialité qu’il avait signé et en fait part à Theo de Raadt.

Plusieurs points intéressants :
* Ces allégations sont invérifiables. Du code de ce type est éminemment complexe à écrire et à auditer (cf la faille Debian SSH, énorme et restée béante pendant plusieurs mois). Une équipe s’est mise à auditer le code en question, mais qu’en conclure si ils trouvent des problèmes ? Cela pourrait aussi bien être un bug. Ils peuvent aussi bien ne pas en trouver, cela ne prouvera pas l’absence de faille.

* Ces allégations sont parfaitement crédibles. La pile IPSEC d’OpenBSD était la première implémentation ouverte (à code source ouvert et réutilisable), et a donc été reprise par de nombreux systèmes. Cela en faisait a priori une cible de choix.

* Surtout : une fois le code complétement audité : qui pourra certifier que cette stack IPSEC est enfin sûre ? OpenBSD est déjà réputé pour être l’un des systèmes les plus audités du monde ; une scrutation de plus est-elle de nature à changer quoi que ce soit à la confiance que l’on peut apporter à la sécurité de ce système ? De ce point de vue, cette crise est un non-événement, car elle ne change rien à cet état de fait.

Open source ou pas, la question de la confiance dans les systèmes de chiffrements – et dans la sécurité des systèmes en général – est de nouveau posée. Ce ne sont certes pas les audits réalisés dans les cadres légaux (comme les critères communs) qui y répondront!

Salutations enfin au courage de Theo de Raadt, qui sait parfaitement que faire pour assurer la confiance à moyen et à long terme. À défaut de certitudes sur la sécurité de l’OS, voici de quoi étayer une conviction sur les intentions de ceux qui gèrent ce projet.

Je vois une sortie de crise, qui à défaut d’être complète, serait intéressante : que Monsieur Gregory Perry publie toutes informations en sa possession sur ces fameuses failles intentionnelles. Personne ne pourra dès lors le traitera de menteur ; on pourra au plus douter qu’il ait tout divulgué…

L’insécurité a son marché, et ses phénomènes d’adoption, analysables de manière très proche à celle dont on considère l’adoption d’une technologie de produits par le marché.
.
(Source : arstechnica )
Le marché de l’insécurité s’étant structuré, les exploits se vendent, s’industrialisent et se propagent très rapidement. On est vraiment très loin des auteurs de virus “sympa” des années 90.
Cette fois-ci, Java est en cause. Tout simplement parce qu’il est devenu universel, installé partout, et en particulier des systèmes Desktop aux terminaux mobiles en tous genres y compris les téléphones dits intelligents, en passant par les serveurs web. Et parce qu’il est, semble-t-il, vraiment facile à attaquer. Et ce qui tourne dans une machine virtuelle Java est bien loin de la couche d’analyse des antivirus.
Java dispose de toutes les qualités requises : la puissance d’un language complet, la difficulté pour les administrateurs de comprendre les tenants et aboutissants en terme de sécurité, un panel d’applications écrites par tout un chacun sans la moindre notion de ce qu’est la sécurité. Et j’oubliais, Java et ses failles sont portables.
Considérons Java du point de l’utilisateur moyen, et regardons les processus à suivre en cas de découverte d’une faille critique dans les versions installées. L’utilisateur doit mettre à jour :
– son ordinateur de bureau
– son téléphone portable
– sa voiture / son gps
– sa webcam, son alarme de maison, …
– bientôt, son frigo
– et j’en oublie
Il peut également tenter de s’assurer que les services en ligne critiques qu’il utilise sont à jour.
Et je ne parle pas du niveau moyen et de la sensibilité à la sécurité du développeur web moyen sur technologie Java.
Quand Java aura été corrigé (est-ce vraiment faisable? je ne suis pas bien placé pour le savoir), ou en tous cas quand le marché se sera doté d’outils pour protéger un peu mieux ses applications Java, nul doute que ce marché de l’insécurité passera à une nouvelle technologie. Pourquoi pas pdf? Notoirement, pdf est un language très puissant, et encore très facile à attaquer. Son tour viendra sur le marché de l’insécurité de masse.
[Edit] : Adobe en est bien conscient, qui annonce le sandboxing de son reader pdf

Tu as été le meilleur des chats… Tous ceux que tu as approchés ont ressenti cette aura de bienveillance et de bien-être que tu dégageais.
Ce 29 juillet au matin, un chauffard a mis fin aux bonheurs quotidiens que tu nous apportais, alors que tu n’avais pas 2 ans.
Tes 9 vies n’ont pas suffi… Je sais que tu resteras irremplaçable et je te souhaite de reposer en paix. Je n’oublierai jamais ma petite usine à ronronner ; ton départ abrupt me laisse un grand vide.
Mon esprit sait bien qu’on ne te verra plus entrer dans la maison et te frotter aux chaises, et pourtant toujours je regarde le soupirail que tu aimais ouvrir, et qui reste fermé.

Comme c’est ironique… Les footeux qui depuis des années adorent brailler, klaxonner à pas d’heure “ON A GAGNÉ” sans la moindre considération pour les gens qui ne s’intéressent pas à ce “sport”, ou simplement essaient de dormir la nuit, sont à présent incommodés par le bruit du stade. C’est quand même dingue, on ne s’entend plus brailler devant sa télé!

Vuvuzelas, pourvu que ça dure 🙂

Je dirais même :
Brrrrruuuuuuuuuuuuuuuuuu!

Le formalisme que nous trouvons dans nos contrats, que la Justice et que les administrations nous imposent m’a toujours fasciné, et, je l’avoue, sa simple existence me dépasse encore.

Je me souviens des jeux de billes dans la cour de récréation, en primaire. Celui qui avait une bille à mettre en jeu la posait au sol, traçait une ligne à la craie. Celui qui voulait gagner la bille se plaçait donc derrière la ligne. Et à ce moment, avant que le lanceur ne passe à l’action, le premier récitait, aussi vite que possible, une phrase, qui était toujours la même. Je ne me souviens malheureusement plus de la formulation exacte, mais cette phrase ressemblait à “Derrière la ligne, pas en biais, sans clin d’oeil, sans rebond” et contenait d’autres mentions “légales”. À l’époque déjà, je trouvais que ce système était “trop”, que nous connaissions les règles, et que les réciter à toute vitesse n’apportait rien à nos échanges.

Le formalisme nous entoure, en particulier dans le “monde numérique”. Notamment, pas un “service en ligne” sans des clauses que, si nous prenions le temps de lire et de comprendre, nous refuserions horrifiés. Je me lance avec quelques exemples : ici, ici ou encore ici (citations non ciblées, je suis sûr qu’on trouve facilement pire). Par chance, nous (les Utilisateurs) sommes trop paresseux pour ce faire. Je dérive du sujet, et m’arrêterai donc ici, mais la CNIL a du pain sur la planche pour sensibiliser le public à la maîtrise de ses données personnelles.

Mais pour conclure à charge des amateurs de formalisme, à quoi ressemblerait notre vie si nous devions intégrer ces clauses légales partout? Acheter du pain chez le boulanger, conduire les enfants du voisin, promener son chien… sont autant de prises de risques insupportables, n’est-ce pas ?

Il y a un peu plus d’un an, nous avons été frappés par la fameuse faille OpenSSL sur les systèmes Debian.
Pour résumer rapidement, l’espace de définition des clés de chiffrement s’est trouvé réduit de plusieurs milliards de milliards à 32767. Donc, si vous disposiez d’une clé SSL vulnérable, je n’avais que 32767 essais (maximum) à faire pour usurper votre identité sur votre système.

De manière assez curieuse, cette faille est restée très longtemps (presque 2 années!) en production sans que personne ne s’en aperçoive.

Cet article propose une chose que nous aurions pu faire avant (et que nous pouvons faire aujourd’hui) pour détecter ce problème beaucoup plus rapidement. Il s’agit simplement de s’appuyer sur l’audit public. Cette proposition est particulièrement pertinente pour l’utilisation de OpenSSH, mais doit probablement pouvoir s’élargir à d’autres usages.

Voici la proposition : modifier OpenSSH (ou OpenSSL?) pour qu’il compare chaque nouvelle clé publique reçue avec les clés déja connues. Si la clé reçue est la même qu’une clé déja connue, prévenir l’utilisateur.

Voilà, c’est tout.

Bien entendu, certaines personnes (et moi le premier) utilisent la même clé sur plusieurs systèmes. Les personnes qui font cela savent qu’ils le font, et ne seront pas perturbées par l’avertissement. En revanche, quand il s’agira d’une clé fraichement générée, je pense qu’il serait particulièrement intéressant d’être au courant que c’est la même clé.

Voilà, avec un tel système, je pense que 15 jours après la mise en production de la faille OpenSSL, la communauté se serait rendue compte que quelque chose ne tournait pas rond. Mieux vaut tard que jamais, je propose donc de modifier les outils pour lesquels ce type de process peut améliorer la sécurité (pour moi, au minimum, c’est le cas pour OpenSSH).

Les crédits de cette idée vont à X. Desurmont PhD.

Il est de bon ton de nos jours de questionner la salubrité publique de l’utilisation généralisée des téléphones portables, et des antennes déployées sur le territoire, en particulier pour ce qui concerne la santé des enfants. En soi il est extrêmement louable que la société s’intéresse [enfin] au sujet.
Si l’on considère l’évolution de la conception des téléphones, on observe :

1) Miniaturisation. C’est bien d’avoir un téléphone qui tient dans la poche.

2) Disparition de l’antenne extérieure. Et ceci nous est imposé par les marketeux parce que ça fait “has been”. Sauf qu’une antenne extérieure, c’est beaucoup moins d’ondes émises dans nos oreilles, cerveaux et ceux de nos bambins.

Et si on commençait par demander aux fabriquants de nous [re]proposer des téléphones avec antenne extérieure ?

Les crédits de cette idée vont à X. Desurmont PhD.

Ce jeudi 5 février, vous avez peut-être, comme moi, écouté notre Président à la télévision.

Je n’ai pas tout suivi, mais je l’ai entendu expliquer que les milliards d’euros prêtés aux banques feraient des intérêts qui seraient utilisés pour de grandes actions sociales. Voilà une bonne nouvelle.

Merci donc à la crise, sans laquelle ces milliards d’euros seraient restés à dormir sans générer d’intérêts.

Et merci, cher Nicolas, pour cet applomb si savoureux.