Just Another Geek

J'ai commençé à lire mes spams, non pas parce que j'ai des problèmes de montage de chapiteau mais plutôt pour essayer de voir des patterns.

Par exemple, j'ai reçu depuis la semaine dernières une trentaine de spams avec une apostrophe dans la partie locale de l'adresse From:, exemple :

From: "Benny Blair" <Monteverdi'susurious@tamamanours.ru>

Donc j'ai dégainé mon spamassassin et ajouté ça dans mon /etc/spamassassin/local.cf :

header FROM_ADDRESS_QUOTED From =~ /<.*'.*@/
describe FROM_ADDRESS_QUOTED what is this quote in the email address
score FROM_ADDRESS_QUOTED 3.0

J'ai testé sur l'intégralité de mes mails et ça ne déclenche aucun faux-positif.

Qu'est-ce que Gmane ?

Gmane est une passerelle de mailing list vers le protocole NNTP [archive]. Gmane s'inscrit sur les listes et republie les messages dans des groupes.

Pourquoi utiliser les services de Gmane.org ?

Gmane est bon pour la planète :

• Économe : Plus besoin que le serveur de liste envoie N fois le mail en entier à chaque personne alors que vous n'allez en lire que la moitié, rien qu'en sélectionnant les titres.
• Spam : Avant d'injecter les messages, plusieurs traitements anti-spams sont appliqués aux messages avec une efficacité redoutable.
  De plus, si des spams venaient à passer, vous pouvez les marquer vous-même comme tel et les messages seront supprimés après modération, ce qui permettra à d'autres personnes de profiter de votre marquage.
• Inscription facile aux listes : Plus besoin de voir si le gestionnaire de liste est un Mailman, Sympa, ecartis, etc. Vous avez juste à cocher la case du groupe dans votre lecteur de news et vous êtes inscrit.
• Possibilité de lire les groupes en NNTP, mais aussi grâce aux interfaces Web : vous pouvez alors envoyer un lien facilement vers un article donné.

En fait, la seule raison qui pousse les gens à ne pas utiliser Gmane est qu'ils n'utilisent pas de client de news (alors qu'une personne sérieuse utilisera Gnus [archive]). Non, je ne fais pas de la publicité car j'ai reçu mon tee-shirt d'admin [archive] gratuit :)

Maintenant que dans certains milieux non-autorisés, les vulnérabilités de GnuPG se revendent moins cher que les vulnérabilités phpBB, je n'accepte désormais plus les messages signés/chiffrés...
J'rigooooooole... (Copyright Borat)

... Mais je n'accepte plus les mails chiffrés non signés ou non-trustés (enfin si j'étais un vrai parano, c'est ce que je ferais) :)

Ça doit faire bizarre de se réveiller un matin, d'ouvrir les yeux et se rendre compte de la vérité : le produit sur lesquel tu travailles avec amour depuis plus de cinq ans est tout pourri et y a rien à y faire. C'est un peu ce qu'a dû se dire Stefan Esser puisqu'il quitte l'équipe sécurité de PHP [archive]...

Hier soir, lorsque j'ai vu l'advisory CVE-2006-5444 [archive] portant sur Asterisk [archive] et son implémentation Skinny, je me suis dit : chouette, je vais pouvoir utiliser scapy [archive] et mon implémentation Skinny toute prête [archive] pour écrire l'exploit (un integer overflow [archive] entrainant un heap overflow [archive]).

Oui, sauf qu'y a vraiment pas besoin : le bug (pré-authentification s'il vous plait! Excusez moi du peu) porte sur le premier champ du protocole (la longueur du message) dans le premier segment de données, bref rien de passionnant, et y a surtout pas besoin d'utiliser scapy pour faire ça :)

Toujours est-il que je remercie les développeurs Debian pour asterisk_safe qui permet de relançer le daemon lorsqu'il est mort. C'est une excellente solution pour les... attaquants puisque avec le noyau de Debian Sarge par défaut, il n'y a pas de randomization des adresses et la GNU Libc 2.3.2 n'a pas les "mesures de protection" qui permet d'utiliser un simple unlink(). Pour exploiter ça, c'est finger-in-the-noise si on cherche pas à faire compliquer.

Si j'ai le temps, je porterai l'exploit dans Metasploit 3... Mais faut d'abord que je fiabilise mon-mien-tout-crade-mais-qui-marchouille...

Note : Ça fait tout de même mal aux yeux que ce soit le tout premier traitement appliqué au message qui soit exploitable aussi facilement, ça laisse perplexe sur la sécurité du reste... À auditer donc.

Je ne sais pas qui m'en veut mais je dois avoir une poupée voodoo à mon image et une personne n'arrête pas de jouer avec mon destin : j'enchaîne problèmes sur problèmes, aussi bien matériel et logiciel.
Un exemple ? Facile, la corruption de tout mon filesystem avant hier sachant que la seule chose que j'ai faite est de mettre à jour le noyau du 2.6.17 à un 2.6.19.
Je ne vois aucun message de plainte sur lkml donc j'imagine que c'est de ma faute, mais comment ? La machine n'a pas subit de tortures, je l'ai utilisé comme je l'utilise tous les jours depuis deux ans, etc.

Cette boue d'XFS a foutu en l'air tout /, m'empechant de faire quoi que ce soit. J'ai tout de même réussi à faire un xfs_check && xfs_repair (en les relancant plusieurs fois car j'ai des erreurs de segmentation...). Bien sûr, j'ai oublié mon lecteur CD-ROM au boulot, donc pas possible de booter sur un live-CD, arrrrrrrg!

kernel: Filesystem "hda1": XFS internal error xfs_da_do_buf(2) at line 2087 of file fs/xfs/xfs_da_btree.c.  Caller 0xc0220224
kernel:  xfs_corruption_error+0xf9/0x104
kernel:  xfs_da_read_buf+0x3b/0x3f
kernel:  kmem_zone_alloc+0x5a/0xad
kernel:  xfs_da_buf_make+0x27/0x120
kernel:  xfs_da_do_buf+0x73f/0x83f
kernel:  xfs_da_read_buf+0x3b/0x3f
kernel:  hrtimer_wakeup+0x0/0x1c
kernel:  xfs_da_read_buf+0x3b/0x3f
kernel:  xfs_da_node_lookup_int+0x8f/0x293
kernel:  xfs_da_node_lookup_int+0x8f/0x293
kernel:  xfs_dir2_node_lookup+0x41/0xb2
kernel:  xfs_dir_lookup+0xf9/0x11f
kernel:  soft_cursor+0x1f3/0x200
kernel:  bit_cursor+0x528/0x53d
kernel:  xfs_dir_lookup_int+0x40/0x103
kernel:  vn_hold+0x23/0x3e
kernel:  xfs_rename+0x200/0xcb6
kernel:  __d_lookup+0xbf/0x13c
kernel:  xfs_access+0x47/0x4f
kernel:  vfs_permission+0x20/0x24
kernel:  __link_path_walk+0xbe8/0xcd1
kernel:  xfs_vn_rename+0x49/0x84
kernel:  link_path_walk+0xc6/0xd0
kernel:  xfs_iunlock+0x61/0x87
kernel:  xfs_access+0x47/0x4f
kernel:  __mutex_lock_slowpath+0x1c4/0x1cc
kernel:  vfs_rename+0x226/0x3c6
kernel:  sys_renameat+0x179/0x1f8
kernel:  sys_rename+0x27/0x2b
kernel:  syscall_call+0x7/0xb
kernel:  =======================

Une chose est sûre, je réinstalle cette machine en ext3fs bientôt...

Update: : C'est un bug connu [archive] et référencé [archive]. Adieu XFS! C'est le deuxième bug de corruption de données cette année...