Le site kernel.org est le site officiel du développement du noyau linux. Il s'agit d'un site massivement mirroré au travers du monde. Un des serveurs, hera.kernel.org (indisponible à cette heure) a été compromis. Le message du site central est éloquent: "Security Breach". Le message qui suit est une traduction commentée du message initial diffusé sur kernel.org.
La compromission fût détectée fortuitement le 28 Août par un administrateur qui a lu des messages d'erreurs étranges dans le /dev/mem lié à Xnest alors qu'Xnest n'était pas installé... Ceci me fait penser à la vidéo de Nicolas Ruff sur les APT que j'ai visionnée sur le blog de Cédric Blancher. Une des diapositives de sa présentation indique: "Les compromissions sont souvent découvertes par hasard"...
Une seconde analyse attentive du serveur par les administrateurs à montré qu'un troyen était lancé automatiquement au reboot de la machine, signe évident de compromission. De plus les fichiers liés à ssh (openssh, openssh-server et openssh-clients) ont été modifiés et étaient en cours d'utilisation. Apparement le programme malveillant loggait les actions des utilisateurs du système. Une analyse élargie a montré que plusieurs autres serveurs présentaient des erreurs curieuses une fois de plus liées à Xnest, sans qu'il ne soit possible à l'heure actuelle de faire le lien formel entre compromission et messages d'erreurs Xnest. Quoi qu'il en soit, il est conseillé à tous les développeurs noyaux impliqués de vérifier la présence de ce genre de messages sans qu'il ne soit plus donné de précisions (Que faut il chercher? un crash? oops? autre type d'erreur?).
La compromission initiale s'est faite en deux temps selon les administrateurs. L'attaquant aurait utilisé un login/mot de passe (soit faible, soit obtenu par un moyen tiers ce n'est pas précisé) pour obtenir un shell local puis aurait utilisé une faille inconnue pour devenir root. Des recherches sont en cours, une note indique que le noyau 3.1rc2 pourrait bloquer cette attaque sans plus de certitudes.
Une grosse opération de nettoyage est en cours puisque les machines ont toutes été mises off-line pour analyse. Les autorités (haha) américaines et européennes ont été prévenues. Toutes les machines de kernel.org vont être réinstallées. Les 448 utilisateurs de ces machines vont devoir changer de mots de passes et/où de clé SSH. Et enfin tous les fichiers composant le noyau linux sont analysés, ainsi que les tarballs pour s'assurer qu'aucune modification n'y a été effectuée.
Le message d'alerte termine sur une note positive en indiquant que l'attaque est inutile car le mode de développement de liux est basé sur git. Git calcule un hash SHA-1 de chacun des fichiers composant l'arbre des sources. Il n'est donc pas possible de modifier un de ces fichiers, et donc l'attaquant n'a pas de possibilités de "trojaniser" un noyau linux qui sera diffusé par la suite. Un deuxième avantage lié au mode de développement décentralisé de linux fait qu'il existe une quantité innombrable de duplicata de ces sources, permettant ainsi de détecter le changement entre deux versions. Le message termine par ces mots "(we) are confident that our systems, specifically git, have excellent desgin to prevent real damage from these types of attacks".
Dans un sens, oui, ils ont raison, mais je ne suis pas rassuré pour autant. Je ne suis pas développeur, je n'utilise donc pas git, je ne peux donc pas compter sur son mécanisme de checksums élaboré. Je télécharge mes noyaux en tar.bz2 sur un des mirroirs cités plus haut en vérifiant sa signature. Et la vérification de signature, http://www.kernel.org/signature.html, le dit bien: "This signature does not guarantee that the Linux Kernel Archives master site itself has not been compromised.". Donc à l'heure actuelle, je ne vais sûrement pas télécharger de noyaux :-) Le second point qui m'inquiète toujours un peu dans ce genre de compromissions c'est le flou artistique (apache, redhat) qui entoure la compromission. La communication est toute à leur honneur et est je pense essentielle. Néanmoins, j'aimerai également (vœu pieux) un gros travail de communication rétroactif une fois la crise passé pour pouvoir prendre le temps d'analyser cette compromission à froid.
EDIT: les serveurs ne sont toujours pas remontés. Linux Torvalds a choisi de migrer l'arbre des sources sur github.
La compromission fût détectée fortuitement le 28 Août par un administrateur qui a lu des messages d'erreurs étranges dans le /dev/mem lié à Xnest alors qu'Xnest n'était pas installé... Ceci me fait penser à la vidéo de Nicolas Ruff sur les APT que j'ai visionnée sur le blog de Cédric Blancher. Une des diapositives de sa présentation indique: "Les compromissions sont souvent découvertes par hasard"...
Une seconde analyse attentive du serveur par les administrateurs à montré qu'un troyen était lancé automatiquement au reboot de la machine, signe évident de compromission. De plus les fichiers liés à ssh (openssh, openssh-server et openssh-clients) ont été modifiés et étaient en cours d'utilisation. Apparement le programme malveillant loggait les actions des utilisateurs du système. Une analyse élargie a montré que plusieurs autres serveurs présentaient des erreurs curieuses une fois de plus liées à Xnest, sans qu'il ne soit possible à l'heure actuelle de faire le lien formel entre compromission et messages d'erreurs Xnest. Quoi qu'il en soit, il est conseillé à tous les développeurs noyaux impliqués de vérifier la présence de ce genre de messages sans qu'il ne soit plus donné de précisions (Que faut il chercher? un crash? oops? autre type d'erreur?).
La compromission initiale s'est faite en deux temps selon les administrateurs. L'attaquant aurait utilisé un login/mot de passe (soit faible, soit obtenu par un moyen tiers ce n'est pas précisé) pour obtenir un shell local puis aurait utilisé une faille inconnue pour devenir root. Des recherches sont en cours, une note indique que le noyau 3.1rc2 pourrait bloquer cette attaque sans plus de certitudes.
Une grosse opération de nettoyage est en cours puisque les machines ont toutes été mises off-line pour analyse. Les autorités (haha) américaines et européennes ont été prévenues. Toutes les machines de kernel.org vont être réinstallées. Les 448 utilisateurs de ces machines vont devoir changer de mots de passes et/où de clé SSH. Et enfin tous les fichiers composant le noyau linux sont analysés, ainsi que les tarballs pour s'assurer qu'aucune modification n'y a été effectuée.
Le message d'alerte termine sur une note positive en indiquant que l'attaque est inutile car le mode de développement de liux est basé sur git. Git calcule un hash SHA-1 de chacun des fichiers composant l'arbre des sources. Il n'est donc pas possible de modifier un de ces fichiers, et donc l'attaquant n'a pas de possibilités de "trojaniser" un noyau linux qui sera diffusé par la suite. Un deuxième avantage lié au mode de développement décentralisé de linux fait qu'il existe une quantité innombrable de duplicata de ces sources, permettant ainsi de détecter le changement entre deux versions. Le message termine par ces mots "(we) are confident that our systems, specifically git, have excellent desgin to prevent real damage from these types of attacks".
Dans un sens, oui, ils ont raison, mais je ne suis pas rassuré pour autant. Je ne suis pas développeur, je n'utilise donc pas git, je ne peux donc pas compter sur son mécanisme de checksums élaboré. Je télécharge mes noyaux en tar.bz2 sur un des mirroirs cités plus haut en vérifiant sa signature. Et la vérification de signature, http://www.kernel.org/signature.html, le dit bien: "This signature does not guarantee that the Linux Kernel Archives master site itself has not been compromised.". Donc à l'heure actuelle, je ne vais sûrement pas télécharger de noyaux :-) Le second point qui m'inquiète toujours un peu dans ce genre de compromissions c'est le flou artistique (apache, redhat) qui entoure la compromission. La communication est toute à leur honneur et est je pense essentielle. Néanmoins, j'aimerai également (vœu pieux) un gros travail de communication rétroactif une fois la crise passé pour pouvoir prendre le temps d'analyser cette compromission à froid.
EDIT: les serveurs ne sont toujours pas remontés. Linux Torvalds a choisi de migrer l'arbre des sources sur github.
Aucun commentaire:
Enregistrer un commentaire