Ce qui me rappelle le temps béni où je pouvais encore naïvement répondre à mes élèves que l'exploitation d'une pile réseau à distance, bien que pas impossible, n'en restait pas moins peu probable, considérant la relative maturité des protocoles implémentés dans les couches réseau standards de l'époque. Pas impossible, puisqu'on avait bien vu, avec la famille des dénis de service de type teardrop par exemple, comment faire exploser une stack à distance. D'ici à être exploitable, au sens exécution distante de code arbitraire, il restait encore pas mal de boulot à fournir...

Certes, il y avait cette rumeur récurrente d'un exploit distant sur tel ou tel OS, mais qui s'avérait surtout une tentative de social engineering pour exploiter un tcpdump vulnérable. Il y a eu les nombreuses exploitations de drivers Wi-Fi qui donnent grosso modo les mêmes résultats, mais elles visent des éléments tierce-partie qui ne sont accessibles qu'à distance rapprochée. D'autres mentionneront des firewalls personnels ou des clients VPN vulnérables. Mais c'est encore une fois des composants tierce partie. Dans le domaine du remote Windows, accessible depuis le net, sur la pile réseau standard, en configuration par défaut out-of-the-box, pas grand chose.

Pour autant, on le sentait doucement arriver. En particulier avec l'apparition et l'intégration des technologies dites de Zero Configuration, fournies par diverses application comme Bonjour[1], le successeur de Rendez-vous, ou encore le client libre Avahi. Le tout fonctionnant essentiellement à base d'un protocole appelé mDNS[2]. Et je vous l'accorde, le but est on ne peut plus louable. C'est super sympa de pouvoir se plugger sur un réseau et le temps d'un battement de cils d'être capable d'accéder au net, imprimer, voir les partages des voisins, lancer des chats, etc.

Le problème, c'est que derrière tout ça, on a de véritables usines à gaz qui, comme toute usine à gaz qui se respecte, arrivent avec leur lot de failles. Et si ces usines à gaz se révèlent accessibles à distance... Et bien paf le chien. Je m'éloigne un peu de l'exploit qui nous intéresse, mais bon, avec IGMP, on n'est pas non plus très loin des histoires de multicast, hein ?


Bref, tout ça pour dire que derrière toutes les belles fonctionnalités super cools de nos OS modernes se cachent des mécanismes pas triviaux du tout. Ça tient de l'évidence, mais de temps à autres, il semble utile de le répéter. Et aussi de se demander s'il est vraiment sage, voire juste utile, de les activer par défaut. Dans le cas qui nous intéresse, IGMP, considérant le niveau d'utilisation du multicast sur le net, pensez-vous vraiment que ça méritait une activation par défaut ? Ça n'aurait certes pas comblé la faille, je vous l'accorde, mais juste considérablement réduit la surface vulnérable. Ce qui n'aurait certainement pas été un luxe quand on considère l'historique de failles sur ce service...



Je précise quand même à l'attention des étourdis que le correctif pour la faille IGMPv3 est disponible et déployable comme expliqué dans le bulletin de sécurité, c'est à dire, pour l'utilisateur moyen, via Windows Update ou Microsoft Update. Ça me semble plus efficace, dans un soucis de sécurité, de le préciser, plutôt que s'interdire de montrer des vidéos. Enfin, j'me comprends comme dirait l'autre...


Update : Halvar Flake nous avait également offert une vidéo détaillant l'analyse de la faille à l'aide de BinDiff.

Notes

[1] Qui existe aussi pour Windows...

[2] Multicast DNS