Résumé

  • Le correctif du service de résolution de SQL Server 2000 existait depuis juillet 2002, mais Slammer a encore trouvé en janvier 2003 une population accessible assez grande pour en infecter plus de 90 % en dix minutes, selon CAIDA.
  • L’autorité opérationnelle était répartie: Microsoft pouvait corriger et documenter, les éditeurs tiers devaient révéler les copies intégrées de MSDE, les propriétaires d’applications devaient modifier les instances, et les exploitants de réseau devaient avoir préparé un confinement plus rapide qu’une décision humaine.

Le calendrier rassurant

Le 24 juillet 2002, Microsoft publie le bulletin MS02-039. Il décrit des dépassements de tampon dans le SQL Server 2000 Resolution Service, un service en UDP 1434 qui indique aux clients où joindre les instances nommées d’une base de données. Une requête construite à cet effet peut déborder la pile et exécuter du code avec les privilèges du compte de service SQL Server. SQL Server 2000 et Microsoft Desktop Engine 2000 sont concernés.

Le bulletin fournit un correctif, une version de fichier à vérifier et une mesure de réduction du risque: bloquer UDP 1434 lorsque le service n’est pas nécessaire. Un correctif cumulatif associé à MS02-061, publié le 16 octobre, reprend la correction. La vulnérabilité n’était donc pas inconnue le 25 janvier 2003.

Cette chronologie peut produire une illusion. Elle mesure la réaction de l’éditeur, pas l’état du parc. Microsoft maîtrise le paquet corrigé et sa documentation. Il ne maîtrise ni l’inventaire de chaque entreprise, ni les produits ayant installé MSDE comme dépendance, ni les fenêtres de maintenance, ni le processus effectivement chargé en mémoire. Là où l’ancien service restait exposé, l’ancienne règle continuait de s’exécuter.

Running-Code Primacy apporte ici une séparation utile. Le texte annonce la possibilité d’un nouvel état. Le binaire en fonctionnement prouve lequel des deux états gouverne encore la machine.

Un seul datagramme, aucune attente

Slammer, également nommé Sapphire, commence à se propager peu avant 5 h 30 UTC le samedi 25 janvier 2003. Son corps tient en 376 octets. Avec les en-têtes, l’analyse de CAIDA décrit un paquet UDP/IP de 404 octets. Reçu par un service vulnérable, il exploite le dépassement puis fait émettre à l’hôte infecté le même corps vers des adresses pseudo-aléatoires sur le port UDP 1434.

La vitesse ne vient pas d’un grand logiciel sophistiqué. Elle vient de ce que le programme n’attend rien. Il n’établit pas de session et ne demande pas si une cible existe avant de passer à la suivante. Un scanner fondé sur TCP supporte le temps des connexions et des expirations. Slammer est surtout limité par la vitesse à laquelle le serveur compromis et son accès peuvent envoyer.

CAIDA a observé directement environ 26 000 sondes par seconde sur une machine et estimé une moyenne initiale proche de 4 000 par instance infectée. Après environ trois minutes, le débit agrégé dépassait 55 millions de sondes par seconde. Plus de 90 % des hôtes vulnérables accessibles ont été infectés en moins de dix minutes.

Le chiffre de 74 856 adresses infectées distinctes observées pendant la première demi-heure est un minimum, non un décompte mondial. Le générateur pseudo-aléatoire défectueux du ver faisait échapper certains cycles d’adresses aux points de mesure, et une trace précoce a été interrompue après environ deux minutes et quarante secondes. L’incertitude ne change pas la conclusion temporelle: l’étape décisive s’est déroulée avant qu’une chaîne humaine ordinaire puisse autoriser et déployer un filtre.

Le déni de service partait du réseau infecté

Slammer n’est pas une attaque par réflexion. Il ne falsifie pas l’adresse d’une victime pour faire répondre un tiers et ne multiplie pas une petite demande par une grande réponse. Chaque serveur compromis émet ses propres sondes. La variante étudiée n’avait pas d’autre charge malveillante; sa reproduction suffisait.

Dans de nombreux sites, une ou quelques machines remplissaient le premier lien partagé. Les autres systèmes perdaient leur connectivité sans être eux-mêmes vulnérables. Les équipements rencontraient simultanément un volume élevé, beaucoup de petits paquets et une succession rapide de destinations. Processeur, mémoire, files d’attente ou bande passante pouvaient céder. Les instances infectées finissaient même par se concurrencer entre elles.

Une sécurité conçue uniquement comme frontière entrante manque ce mécanisme. Le premier dommage peut être l’usage incontrôlé de la capacité sortante par un composant interne. Le contrôle pertinent appartient alors au réseau local: segmentation, observation des flux sortants, équité des files, limitation ou isolement d’un poste précis. Confier tout le problème à un service de nettoyage externe revient à intervenir après le premier goulot d’étranglement.

MSDE se cachait sous le nom d’une autre application

Microsoft Desktop Engine 2000 pouvait être installé avec des logiciels qui avaient besoin d’un moteur de base de données. L’organisation pouvait donc exploiter le service vulnérable sans avoir acheté ni recensé un produit portant clairement le nom « SQL Server ». CERT/CC signalait expressément que les produits contenant MSDE 2000 étaient concernés.

Cette situation divise la connaissance. L’éditeur du composant connaît la vulnérabilité. Le distributeur connaît l’intégration. Le responsable applicatif connaît l’usage métier. L’équipe réseau voit le port. Si les quatre inventaires ne se rejoignent pas, personne ne sait répondre à la question simple: quel processus vulnérable tourne réellement ici ?

Une campagne crédible vérifie donc l’identité exécutable: service chargé, version du fichier, propriétaire, dépendance, clients autorisés et chemins d’accès possibles. Le numéro d’une demande de changement ne remplace pas ces observations.

L’histoire de MS02-061 ajoute une contrainte légitime. Microsoft a réédité le correctif SQL Server 2000 parce que la combinaison initiale pouvait perturber l’exploitation dans certaines circonstances; un correctif non lié à la sécurité et un nouvel installateur ont été intégrés. Cela ne transforme pas l’inaction en prudence. Cela montre que l’adoption relève de l’exploitant qui doit tester la modification, assumer son calendrier et produire la preuve que le bon code fonctionne.

L’heure des filtres est arrivée après les dix minutes

Selon CAIDA, beaucoup de sites ont commencé à filtrer le trafic destiné à UDP 1434 dans l’heure. La signature était favorable à une réaction: paquet identifiable, port précis, peu d’usage Internet légitime dans de nombreux réseaux. Malgré ces conditions presque idéales, le filtrage humain a commencé trop tard pour limiter substantiellement le nombre de premières infections.

Il a néanmoins réduit la charge persistante et contribué au rétablissement. Cette différence importe. Prévenir l’infection, contenir le trafic et corriger le serveur sont trois résultats distincts. Un filtre de frontière peut aussi ne rien voir d’une propagation entre segments internes. Les recommandations de Cisco distinguaient donc des ACL de routeur et des contrôles au niveau des VLAN, tout en reconnaissant que certaines applications avaient réellement besoin de 1434.

La réponse n’est pas un pouvoir automatique sans limites. Une règle locale peut être autorisée à l’avance lorsque plusieurs faits coïncident: taille et destination caractéristiques, éventail brutal d’adresses et débit sortant incompatible avec le rôle de l’hôte. Elle peut ralentir, placer en quarantaine ou déplacer vers un chemin restreint. Son périmètre, sa durée, ses exceptions, les preuves conservées et le retour arrière restent décidés localement.

La spécification commune minimale tient en trois résultats: identifier le composant, supprimer l’accessibilité injustifiée et empêcher un poste de monopoliser une ressource partagée. Chaque réseau garde le choix de la mise en œuvre.

Les quatre reçus de l’adoption

L’éditeur doit fournir une version corrigée identifiable et un chemin d’installation viable. Le distributeur doit relier le composant intégré au produit et au client. Le propriétaire d’application doit prouver la version chargée, l’exposition et la dépendance. L’exploitant du réseau doit montrer par les flux et les essais qu’un seul endpoint ne peut pas prendre le lien entier.

Aucun reçu ne remplace l’autre. Le pare-feu réduit l’exposition sans réparer le binaire. Le correctif ne justifie pas un service public inutile. L’inventaire peut être périmé. Une quarantaine trop large peut être politiquement impossible à déclencher. La solidité vient de la confrontation entre ces preuves.

Cette répartition n’exige pas que Microsoft administre les réseaux de ses clients, ni que les opérateurs de réseau modifient SQL Server. Elle exige que chaque acteur rende visible l’état nécessaire à la décision suivante, et que celui qui porte les conséquences conserve le droit d’exécuter ou de revenir en arrière.

Limites de preuve

Les sources démontrent un correctif antérieur, un ver transporté par un seul datagramme, au moins 74 856 adresses observées et une propagation décisive en quelques minutes. Elles ne démontrent pas que toutes les installations SQL Server ou MSDE étaient publiques, que le minimum observé constitue le total, ni que chaque panne médiatisée a la même cause.

Elles ne décrivent ni usurpation de source, ni réflexion, ni vol de données, ni charge destructrice supplémentaire dans la variante observée. La conclusion est plus étroite: un correctif publié ne retire aucun pouvoir au code qui continue de tourner. Quand la propagation précède le temps humain, l’organisation doit borner à l’avance des actions automatiques et vérifier l’adoption dans les versions, les sockets, les flux et les exercices. La publication ouvre le changement; l’exécution le rend réel.

Sources