Il s’en est fallu de peu... Confrontée à une panne, l’équipe du projet open source a dû reconstruire d’un de ses clusters Kubernetes, perdant au passage une partie de sa base de données utilisateurs. Un problème aux répercussions lourdes en termes de sécurité, puisque n’importe qui aurait pu prendre le contrôle des plugins publiés par les utilisateurs, de sorte à être en mesure de pousser par exemple du code malveillant.
C’est un bug comme il en existe tant d’autres. Le 2 juin, Jenkins rencontrait une panne. Olivier Vernin, ingénieur chez Cloudbees et Infrastructure Officer pour la solution de CI/CD open source, expliquait que Jenkins rencontrait des problèmes avec l’un de ses clusters Kubernetes. Alors qu’il tente de mettre à niveau le cluster vers la dernière version stable, “en espérant que la mise à niveau de la version redémarrerait chaque nœud et que les instabilités seraient résolues dans l'une des versions ultérieures”, la situation s’est aggravée, les services cessant de fonctionner alors que les ressources y étaient toujours en cours d’exécution... En bref, la panade comme il en arrive souvent en informatique.
Pour remédier à cette panne, il est décidé de recréer le cluster. Mais, corollaire de la panne, Jenkins perd trois mois de modifications LDAP (un protocole interrogeant et modifiant les services d'annuaire ) du fait d’une sauvegarde “cassée” par la panne. Rien de très grave en apparence, sinon l’impossibilité pour de nombreux utilisateurs d’accéder à leur compte. “Nous avons restauré la dernière sauvegarde disponible, de sorte que les modifications récentes sont perdues. Nous étudions les options possibles pour restaurer entièrement ou partiellement les modifications, mais aucune bonne nouvelle pour le moment. Si vous fournissez votre ID de compte, je vais essayer de le réinitialiser manuellement” répondait Oleg Nenashev, responsable de la maintenance de Jenkins à un utilisateur inquiet.
Je te tiens, tu me tiens, par les privilèges...
Soudain, le 9 juin, sur ce même fil de discussion, un utilisateur avertit : “nous venons de découvrir le problème par accident : impossible de se connecter ou de réinitialiser le mot de passe. Lorsque nous avons créé un nouveau compte pour notre société, il a automatiquement assumé tous les droits d'accès et de propriété d'extension pour le plugin que nous avions publié il y a quelques semaines”. Tout va bien pour cette société donc, aucune raison de se plaindre... à un détail près : la manoeuvre indique que n’importe qui “peut reprendre les comptes existants d'autres fournisseurs, puis envoyer des mises à jour logicielles malveillantes aux clients”.
Panique à bord chez Jenkins, qui gère près de 10 millions d’artefacts. Après ce message, l’équipe décide de bloquer tous les téléchargements d'artefacts vers l'instance Jenkins Artifactory, avec pour dommages collatéraux de bloquer les téléchargements de certains binaires. Elle mène également un audit de sécurité de toutes les versions d’artefacts publiées entre les 2 et 9 juin, sans déceler d’artefact malveillant. “Le flux de publication de plugin nécessite un accès à GitHub afin de pousser les validations de publication, donc un attaquant devrait contrôler les comptes Jenkins et GitHub d'un utilisateur pour soumettre sa version d’un plugin” rappelle Oleg Nenashev.