L’infrastructure de Canonical a subi une puissante attaque DDoS, perturbant le fonctionnement des dépôts, de Launchpad et du Snap Store. Les utilisateurs d’Ubuntu n’ont pas pu obtenir de mises à jour du système et des paquets pendant plus de 24 heures en raison d’une surcharge artificielle des canaux de communication.
L’infrastructure serveur de Canonical, qui assure la distribution des distributions Ubuntu et des composants associés, est devenue la cible d’une attaque DDoS prolongée. Les attaquants génèrent un flux de fausses requêtes se comptant par millions par seconde, ce qui entraîne l’épuisement de la bande passante des interfaces réseau et des ressources de calcul des nœuds frontaux.
L’attaque a touché des segments critique de l’écosystème : les miroirs HTTP/HTTPS contenant les paquets (dépôts APT), le système de compilation et de publication d’applications Launchpad, ainsi que les backends du Snap Store. En conséquence, les requêtes client de apt, snapd et curl sont soit perdues en raison de dépassements de délai des connexions TCP, soit rejetées par les équilibreurs de charge placés en mode dégradé.
La situation est aggravée par la divulgation parallèle d’une vulnérabilité dans le noyau Linux (élévation locale de privilèges vers root). Des correctifs pour cette vulnérabilité ont déjà été publiés sous forme d’images noyau et de modules mis à jour, mais leur livraison vers les machines finales est entravée. Dans les environnements d’entreprise, les systèmes de gestion de configuration automatisés enregistrent des codes d’erreur HTTP 503 et 504 lors des tentatives de synchronisation des dépôts locaux avec les miroirs upstream.
La coïncidence de l’attaque DDoS contre l’infrastructure de mises à jour avec la publication d’un correctif pour une exploitation locale d’élévation de privilèges root dans le noyau crée un vecteur dangereux de compromission différée. Même en préservant l’intégrité des paquets déjà installés, l’impossibilité d’appliquer la version corrigée du noyau transforme chaque compte non privilégié en un potentiel de prise de contrôle complète du système pendant la durée de l’indisponibilité des services de Canonical.