L'explication officielle attribue l'incident à un problème de gestion de charge sur les serveurs d'authentification déclenché par un flood de requêtes d'authentification imputables à un nombre massif de reboots des utilisateurs Windows suite à la série de mises à jour publiée par Microsoft mardi dernier 14 août. Laquelle est fort sympathique ceci dit : six failles critiques et trois importantes y sont corrigées. Une bonne belle brochette d'été que je vous conseille de ne pas manquer...

Cette explication est-elle crédible ? L'est-elle plus que cette faille publiée vendredi ? Dans la mesure où l'exploit posté avec n'est qu'une vaste blague, clairement. L'exploit en question, le voici :

#!/usr/bin/perl
# Simle Code by Maranax Porex ;D
# Ya Skaypeg!!

for ($i=256; $i>xCCCCC; $i=$i+256){
$eot='AAAA' x $i;
call_sp();
}
exit;

sub call_sp(){
$str="\"C:\\Program Files\\Skype\\Phone\\Skype.exe\"
                     \"/uri:$eot\"";
}

Que fait donc ce magnifique code Perl ? À part boucler dans le vide, rien. La fonction call_sp() ne fait qu'affecter une chaîne à la variable $str, laquelle n'est jamais utilisée. La boucle quant à elle ne fait qu'appeler call_sp() et n'en fait donc pas plus. Tout cela manque cruellement d'un system($str) ou quoi que ce soit du même tonneau. Et, quand bien même il y aurait quelque chose du genre, à part déclencher un éventuel crash du client du fait de la taille croissante de $eot, j'ai du mal à voir comment cette chaîne pourrait être interprétable comme une URI valide. Intox donc ? Plus que probable.

L'explication de Skype tient-elle mieux la route ? Un peu mieux forcément. Comme l'a montré l'étude réalisée par mes collègues, dont je vous recommande les deux jeux de slides présentés à Recon en 2006, l'authentification est le talon d'Achille de ce réseau peer-to-peer, dont toutes les fonctions sont distribuées, sauf celle-ci. Il n'est donc aucunement étonnant que le crash vienne de là.

Les raisons évoquées sont quant à elles un peu difficiles à avaler et appellent forcément la discussion, en particulier cette histoire d'update Microsoft. En effet, comme son sobriquet l'indique, le "Patch Tuesday" se produit le mardi. Pas le mercredi, et encore moins le jeudi. Si je concède facilement que tous les utilisateurs de Windows de par le monde ne soient pas rivés à leur clavier pour télécharger le jeu de patches mensuel, je trouve relativement étonnant qu'autant se soient donnés le mot pour procéder à leur mise à jour jeudi matin. En tout cas suffisamment pour mettre à genoux l'ensemble des serveurs prévus à cet effet. On s'attendrait plutôt à un pic le mercredi. De plus, pourquoi celle-ci précisément ? Pourquoi pas celle de juillet ? Ou de juin ? Ou n'importe quelle autre ? Aucune raison particulière manifestement, d'autant que Microsoft n'a rien constaté d'inhabituel ce mois-ci.

La seule hypothèse qui à mon avis tient la route, c'est l'introduction d'un bug dans leur système, côté serveur et/ou client, et c'est ce bug qui les a empêché d'encaisser la charge normalement. C'est à peu près ce que Skype avance dans une seconde explication publiée aujourd'hui, au détail près qu'ils restent très flous. On nous explique que lors des updates précédentes, les "facteurs d'une inondation parfaite n'étaient pas réunis"[1]. Quant à nous expliquer ce que sont ces facteurs, rien. Et cela n'a rien d'étonnant considérant les précédentes communications de Skype.

Démonstration par la pratique... Pendant l'étude que je mentionnais précédemment, un heap overflow a été découvert. À en croire l'advisory publié par Skype, il n'est pas exploitable ; un crash tout au plus, éventuellement d'autres conséquences imprévisibles[2]. Sauf que comme cela a été démontré à plusieurs reprises, ce bug est clairement exploitable, de manière stable et sur la plupart des plate-formes impactées, dont Windows XP SP2. Le tout en UDP. Alors forcément, quand on lit "The Skype system has not crashed or been victim of a cyber attack. We love our customers too much to let that happen"[3], ça fait un peu sourire...

Un bug, soit. Reste cependant l'arrêt des téléchargements. Pourquoi diable empêcher les utilisateurs de télécharger Skype ? Pour économiser de la bande passante ? J'en doute. Dans un tel cas, la bande passante n'est certainement pas le facteur limitant. C'est plutôt la complexité. En effet, la phase de login implique le calcul d'une signature RSA par le serveur d'authentification sur une clé publique générée par le client, opération gourmande en ressources s'il en est. Si le problème, se situe en effet dans l'algorithme de répartition de charge côté infrastructure, et aucunement dans le client, aucune raison de couper les téléchargements. Et devinez se qui va se passer quand les téléchargements seront réouverts ? Une nouvelle version sera mise à disposition pour Windows, la 3.5.0.214 du 17 août. Curieux, non ?

Alors si on fait la somme, on a :

  • des gens qui font tout pour cacher le fonctionnement de leur outil ;
  • des gens qui rechignent à communiquer ;
  • un gros plantage ;
  • une excuse foireuse ;
  • des arguments flous ;
  • un client mis à jour dans la foulé.

Je ne sais pas vous, mais ça sent le bon gros bug, probablement exploitable. C'est en tout cas le consensus qui semble se répandre parmi les observateurs, devant les arguments de Skype. Que quelqu'un ait pu le déclencher ou pas est une autre question dont personne, en dehors de cercles très fermés, n'aura probablement la réponse. Reste que les faits sont là, et ne me semblent pas adhérer très fort à la thèse officielle. Toujours est-il qu'à l'heure qu'il est, l'orage est passé. Et la pluie sèche vite dans le petit monde de la sécurité informatique...


Cependant, alors que tout le monde se concentre sur les effets négatifs de ce problème, force est de constater que cet incident a paradoxalement prouvé autre chose. Même sans infrastructure d'authentification, le réseau tourne parfaitement bien, montrant ainsi qu'il est bigrement résilient. Parce que si personne ne pouvait s'authentifier, les utilisateurs ayant une session en cours n'ont pas été dérangé, pas plus que ceux dont les éléments d'authentification étaient sauvegardés, ce qui revient à conserver bien au chaud son bi-clé avec sa clé publique dûement signée par Skype.

Comme quoi, il n'y a pas que du mauvais dans tout ça...


Petite note d'humour chez User Friendly...

Notes

[1] "other factors of a “perfect storm” had not been present"

[2] "Since the attacker cannot control the address where the data is written, the most likely effect will be that the Skype will abort execution due to an internal error, although other unpredictable behavior is possible"

[3] Le réseau Skype n'a ni crashé, ni été victime d'une cyber-attaque. Nous aimons trop nos utilisateurs pour laisser de telles choses se produire.