Just Another Geek

Un instrument de ma boîte à outils est ftpls [archive] : un tout petit programme Perl qui sert à lister un répertoire FTP. Son seul intérêt est qu'il comprend une format string pour strfime() pour désigner le répertoire à lister.

Imaginons par exemple, pure spéculation, que votre serveur de fichiers favoris de fichiers légaux mettent quotidiennement ses nouveaux fichiers dans le répertoire NEWS/$day-$month/. Ca donne ça :

$ ftpls -h w4r3z.4ever.example -e 'NEWS/%d-%m'

Vous ajoutez ça dans votre crontab quotidien et zoup!

En attendant que Phil [archive] les intègre (soumis il y a maintenant quelques mois :p), voici quelques patches pour net2pcap [archive] : un tcpdump -w très allegé et qui a pour but d'être le plus simple, secure et auditable possible.

Ces quelques patches [archive] ajoutent les fonctionnalités suivantes :

• Écriture des fichiers en mode O_LARGEFILE [archive] (pour les fichies pcap de tailles supérieures à 2 Go)
• Ajout d'un fichier de PID [archive], pratique pour lancer via start-stop-daemon
• Révocation de privilèges [archive] comme j'en avais déjà parlé [archive]
• Chrootage du processus [archive]
• Correction de bug pour PERROR() [archive]

Oui, je les publie seulement pour ne pas les perdre comme ça m'est déjà arrivé et devoir les réécrire...

Aujourd'hui, nous sommes un peu impuissants (surtout un certain F. R*nal par son grand age) face aux vulnérabilités clients : chaque semaine, une nouvelle faille sort dans Firefox, Thunderbird, Gaim, Skype, etc.
Tout le monde est potentiellement vulnérable (sisisi, même les gens sous Lynx) en cas d'attaque ciblée. Quelles sont les solutions ?

Mettre en oeuvre un système PaXé [archive] sur une machine orientée desktop est contraignant : tous les logiciels pas libres (comme le plugin flash propriétaire) vont commencer à segfaulter en permanence et on va finir par whitelister tous les binaires posant problème : on ne fait que déplacer le problème.
De plus, je ne suis même pas sûr que les vulnérabilités de Firefox seraient détectées (par exemple lorsque ça touche le moteur Javascript).

À défaut d'avoir une solution protégeant les applications, il faut essayer de minimiser l'impact d'une vulnérabilité. Ainsi, SELinux apporte une solution concrète et fiable : on applique à chaque application une politique de sécurité, on déclare ainsi toutes les actions que ce processus peut faire. L'exemple classique (limite bidon) sorti tout le temps est que Mozilla Firefox ne doit pas avoir accès à /bin/sh par exemple, je dis bidon car un attaquant déterminé pourra toujours s'en sortir en ajoutant une backdoor dans ~/.bashrc, cela marcherait car Firefox peut sauvegarder ses fichiers n'importe où!

Pourquoi ce n'est pas plus populaire que ça ? Car les distributions n'étaient pas très ouvertes à son entrée : il faut écrire les règles, gérer celles-ci lorsqu'on installe/supprime le logiciel, tester, etc.

Pour Debian, l'idée commence à germer dans la tête des développeurs qui aimeraient bien voir SELinux activé par défaut dans la future release de la distribution [archive]. C'est un très bonne nouvelle si ca marchait tout seul pour les paquets les plus populaires (navigateur et messagerie instantannée).

Bonjour, je m'appelle Theo de Raadt et aujourd'hui, je vous apprends la courtoisie [archive]. Pour la peine, ca me ferait bien plaisir de voir un exploit du même style que celui de Gobbles à l'époque. N'aurait-il pas appris la leçon ?

La recherche Google sur Ricard [archive] est intéressante : le deuxième résultat est... le site de Richard Stallman [archive].

J'aime Dave Aitel et sa pensée sur la "sécurité" de MacOS X [archive] :

« If I did a reasonably good translation, then my comment would be that perhaps it's because OS X users are so horribly bad at security that they never notice when they get hacked? This can be compounded by hackers not doing obvious things like stealing money from their OS X targets or putting up pop-ups, etc. Likewise, I think it would be affected by OS X being rarely used in a corporate environment, and hence not protected by the typical corporate IT trappings. »

Juste ce billet de mauvaise foi contre les intégristes Mac Breton (non, c'est pas contre toi Arnaud)...

La killer-app de gajim [archive] par rapport aux autres clients Jabber est qu'il est potentientellement plus difficile d'exploiter ce client pour la simple raison qu'il est écrit en Python.

En effet, si on regarde les vulnérabilités publiques de gaim [archive] (logiciel écrit en C), elles touchent toutes à des débordements de buffers ou autres joyeusetés des langages des années 80 :)
Bien sûr, gajim a sûrement des bugs de sécurité, algorithmiques, mais ça signifie que les chercheurs devront se passer de grep et compagnie... On est tranquille :)

Rien que pour ça (et aussi un peu pour ton support natif d'OpenPGP), gajim, malgré ta lenteur, je te garde!

L'article How to Memorize 100 Passwords in 10 Seconds [archive] (via fr.misc.cryptologie [archive]) approche le problème de génération des mots de passe et la multiplication des logins/mots de passe différents.
La solution proposée par Jean-Philippe Aumasson est intéressante et doit ressembler à quelque chose comme ça (à vérifier dans les sources):

 
int passwords[maxpasswords][lenpassword]; /* avec lenpassword = lenpassword/4 */
int i, j;

srand(masterkey);

for (i=0; i < maxpassword; i++) {
  for (j=0 ; j < lenpassword ; j ++)
       passwords[i][j] = rand();

  srand(passwords[i][0]);
}

Ce tableau indexé correspond à n mots de passe disponibles. L'intérêt d'utiliser exclusivement rand() permet de ne pas compromettre p[n+1] ou p[n-1] si p[n] était découvert (car les passwords sont en ASCII, donc chaque octet généré est modulo la taille de l'alphabet). Notons que cela est vrai si et seulement si le PRG est considéré sûr et que la taille de l'alphabet est assez grande.

L'intérêt, face aux gestionnaires de keyring comme pwsafe [archive] ou revelation [archive], est que cet algorithme vous permet de ne pas avoir à vous balader avec votre keyring partout, vous avez juste besoin du programme, votre master key en tête... et d'une liste qui associe pr0nwild.com à l'index n de votre table de mot de passe.

Tout ça pour dire que je n'ai toujours pas trouvé un gestionnaire de mots de passe correct avec les fonctionnalités suivantes :

• Chiffrement standard (cad déchiffrable dans openssl) du keyring,
• Frontend graphique,
• Frontend console,
• Pas constamment cassé comme revelation dans Debian,
• Plus fonctionnel que pwsafe;

Update quelques heures plus tard : En fait, je ne sais pas ce qui est le mieux ; une taille d'alphabet grande ou petite ? Plus elle est grande, plus les caractères du password seront aléatoires, mais la difficulté de retrouver le mot de 32 bits à partir du modulo sera diminué... Enfin je me comprends...

Une chose est sûre, si je dois acheter un nouvel ordinateur, le chipset sera Intel après l'annonce faite sur LKML : Announcing free software graphics drivers for Intel i965 chipset [archive].

Ou alors on attends les résultats du rachat d'ATI par AMD [archive]...

Comme je l'avais indiqué dernièrement, j'ai changé d'adresse mail ainsi que de clef GnuPG et il est temps que je me sépare de l'ancienne clef (0x09223052 [archive]) en faveur de deux clefs, l'une perso [archive] et l'autre professionnelle [archive].

Pensez à "truster" ma clef pour ceux qui l'ont déjà fait pour l'ancienne, une preuve que c'est bien moi est d'avoir signé la page d'explication de la révocation et les nouvelles clefs [archive].

% wget http://chdir.org/~nico/revocation-gpg-0x09223052.txt
% gpg --verify revocation-gpg-0x09223052.txt

J'avais jamais pensé à configurer xpdf, voila qui est fait.

% cat ~/.xpdfrc
psPaperSize A4
initialZoom width
antialias yes
errQuiet yes

Les options intéressantes sont errQuiet et initialZoom en fait.

Pourquoi réimplémenter le support des filesystems dans les bootloaders (tel que Grub) alors qu'ils sont déjà disponibles dans le noyau Linux ? C'est en partant de cette problématique que les développeurs de kboots [archive] ont développé un bootloader basé sur... le noyau Linux lui-même.

Le fonctionnement idéal de kboots est qu'une fois le stage1 chargé, il lance le noyau trafiqué avec son propre initramfs contenant une mini distribution basée sur µlibc et busybox. Dès lors, le menu de sélection peut s'afficher (qui tourne en userspace). Jusqu'ici, rien d'extraordinaire, mais voyons plutôt le potentiel de ce genre de bootloader :

• Support natif de tous les filesystems (et il n'y a alors plus le support b0rken d'XFS comme dans Grub) de base,
• Accès à toutes les fonctionnalités du noyau Linux et de la mini-distribution integrée. Par exemple, vous pouvez faire tourner un sshd (ok, c'est un dropbear) dans le bootloader ce qui est pratique si vous vous êtes complétement foiré dans la configuration de votre noyau hebergé dans une salle aux USA.
• Vous pouvez booter n'importe quel device supporté par Linux : Firewire, USB, Flash, etc.
• Et même par le réseau : FTP, HTTP, TFTP, etc.

Je pense qu'il y a un vrai potentiel à kibboutz [archive]^Wkboots. Après essai (et la compilation pendant une heure de tout ce qu'il fallait dans une petite VM), ca marche bien mais :

• C'est tout de même lent : il faut attendre le temps de boot d'un noyau Linux classique, donc au moins 30 secondes, puis le vrai noyau est lançé via kexec donc encore 30 secondes d'attente
• C'est testé sur x86 only :(
• Il n'y a pas encore le support de système autre que Linux
• Le stage1 n'est pas encore implémenté ! Donc en gros, il faut lancer kboot via votre bootloader favori. Pas glop mais ca marche très bien.

Même si certains médisants du bureau ne prennent pas au sérieux cette solution, je trouve ça très prometteur et j'envisage d'utiliser kboots sur des serveurs lointains...

Bonjour, je suis un gros boulet ! [archive]

Mon email par défaut a changé, c'est désormais nico@ chdir.org. Comme ma clef GPG [archive] a déjà trop d'UID, j'ai préféré en générer une autre [archive] que j'ai contre-signé, et vice-versa.

Le SSTIC est déjà terminé, ces trois jours ont été parfaits puisque les organisateurs avaient très bien géré le temps (l'espacement entre les pauses ainsi que leurs durées) et pour une fois, même les speakers étaient à la minute près.

Et puis, le SSTIC, c'est trois jours de conférences mais surtout 3 nuits courtes et très arrosées, surtout pour un certain speaker qui voulaient se battre avec le videur et un autre qui avalaient des verres (la vidéo circule...).

Quant à moi, pour tenir la demie heure, j'ai dû retirer la moitié de mes slides et éluder les parties où le code assembleur était majoritaire mais autrement, à part ça et un petit problème de voix, ça c'est bien passé :)

Note: Je n'ai pas réussi à avoir une seule photo nette (salle trop sombre), donc si vous en avez, partagez !