Commençons par le supposé exploit. On m'a objecté qu'il pourrait s'agir d'un code "désamorcé", laissant au lecteur attentif et consciencieux le soin de le corriger. Ce ne serait effectivement pas la première fois qu'un PoC serait posté avec quelques lignes manquantes pour décourager le premier script kiddy venu. Comme je n'ai pas envie d'en écrire des tartines, je vous laisse le soin de lire le billet de Francesco "ascii" Ongaro sur ush.it.

En résumé, si Skype possède effectivement une gestion d'URI documentée qui a fait l'objet de quatre failles, ces dernières n'ont affectées que le client, jamais l'infrastructure. La construction de l'exploit n'est ensuite pas cohérente avec la description de la faille et l'exploitation d'un dépassement de tampon. Grosso modo, ça boucle pas au bon endroit.

Un autre problème que je vois est le format de l'URI qu'il faut passer au gestionnaire. D'après la documentation, une URI Skype commence par <em>skype:</em>, suivi immédiatement d'une cible qui peut être un service, un login, etc. et enfin une action. Si par exemple je veut appeler mon pôte Nanard, je vais demander une URI du type skype:nanard?callto. Comme le client interprête l'URI[1], si celle-ci n'est pas valide, aucune chance que ça finisse sur les serveurs...

Bref, vous l'aurez compris, je n'ai pas franchement l'impression que cet exploit donne le moindre crédit à cette annonce.


Côté "Patch tuesday", on m'a fait la même remarque que Dave Korn sur Daily Dave, à savoir que l'accroissement quasi-exponentiel du nombre d'utilisateurs de Skype ait pu faire franchir un cap inattendu et fatal à l'infrastructure. Cette progression n'en est pas moins anticipable, et il est donc possible de s'y préparer. Les opérateurs de Skype auraient donc pêché par manque de clairvoyance ?

Une autre objection porte sur les les reboots. Les six patches critiques d'août nécessitent un redémarrage de la machine et trois d'entre elles touchent pratiquement toutes les plate-formes. En juillet par contre, trois patches nécessitant un reboot portent sur des composants optionnels[2], le dernier sur Vista. Quant à celle de juin, il serait possible de l'appliquer complètement sans rebooter. Il faut revenir à celle de mai pour repasser par un reboot obligatoire à large échelle. Alors pourquoi pas en mai ? Facteur d'échelle ?

Reste ce décalage de quarante-huit heures entre la publication des patches et la panne. Le décalage pourrait être dû à l'installation automatique des mises à jour. Si aucun utilisateur n'est logué, la machine reboote. Dans le cas contraire, l'utilisateur est invité à le faire ou à repousser l'échéance. Mais si aucune action n'est prise dans les cinq minutes, la machine reboote. En outre, le client Skype ne se relancera au mieux que lorsque l'utilisateur se loguera à nouveau et n'utilisera les serveurs d'authentification seulement si le login automatique n'est pas activé... Autant de paramètres qui relativisent cette histoire de délai. Pour autant, si quarante-huit heures me semble encore un peu long, ça entre dans le domaine du crédible. Par contre, ça n'explique toujours pas la nécessaire concentration des redémarrages dans le temps, concentration que le jeu des fuseaux horaires et du bon vouloir des utilisateurs tend à diminuer. C'est d'ailleurs, paraît-il, ce qui sauverait les plate-formes de téléchargement de Microsoft ;)


L'explication la plus intéressante trouvée à cette heure me semble être celle de Julian Cain, ancien programmeur chez Kazaa, postée en commentaire sur GigaOM. Le coupable selon lui serait la corruption des données permettant aux supernodes de "voir" l'organisation du réseau Skype, et donc de se réorganiser en cas de problème[3]. Cette corruption aurait fait perdre aux supernodes le lien avec la maison mère[4]. Dans ce cas, le supernode abandonne son status, déconnectant les clients qu'il gère. Ceux-ci restent dans cet état jusqu'à ce qu'ils trouvent un autre supernode pour les accueillir. C'est donc un effet domino qui conduit à l'écroulement quasi-total du réseau.

Si l'explication est élégante, elle n'est cependant pas compatible avec le fait que les clients déjà authentifiés n'aient apparemment pas été impactés par la panne, fait qui reste cependant assez controversé. En effet, ce ne serait alors plus un simple problème d'authentification, mais carrément de réseau, et même un client logué aurait perdu l'accès, se retrouvant dans l'impossibilité de faire quoi que ce soit. Et c'est à mon avis l'explication qui tient le mieux la route jusqu'à présent, à ce problème de login automatique près...


Sur la mise à jour du client, on argumente en croisant avec la théorie précédente. Cette mise à jour serait sortie dans l'urgence pour rediriger les clients vers de nouveaux supernodes sains par modification de la liste d'adresses codées en dur dans le binaire. Je ne sais pas vous, mais ça me semble un peu tiré par les cheveux. Pas plus que tout ce qu'on a pu raconter, d'ailleurs...


Et pendant que beaucoup s'interrogent et reprochent à Skype son manque de transparence, ces derniers ont pris le taureau par les cornes et se sont montrés plutôt beaux joueurs. Dans un email plein à craquer de sincérité et d'humilité, ils présentent leurs plus plates excuses à ceux de leur utilisateurs qui sont abonnés à un ou plusieurs services payant, leur offrant généreusement sept jours gratuit pour se faire pardonner.

Un beau coup de communication et de marketing pour récupérer le coup auprès de ceux qui comptent vraiment : les utilisateurs. Car la communauté des afficionados de la sécurité peut bien s'émouvoir tant qu'elle veut, on ne parlera plus de cette affaire dans deux semaines et Skype continuera sur sa lancée...

Notes

[1] Sinon, il aurait été difficile de l'exploiter par ce biais...

[2] LDAP, .Net, IIS.

[3] Ce qu'ils appellent le "self-healing process".

[4] Ce que Julian appelle "clear route".