Petite piqure de rappel d’après GHOST (qui vaut pour tout le monde en fait)

Cet article a été publié il y a 9 ans 2 mois 28 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

GHOST, c’est la dernière info « brûlante » dans le petit monde de la sécurité des systèmes Linux. Les articles sont nombreux, je ne vais donc pas perdre mon temps à redétailler la faille (Stéphane Bortzmeyer en fait un bon résumé en français, ce qui n’est pas du luxe), une sombre histoire de dépassement de mémoire-tampon sur des fonctions qu’on pensaient oubliées depuis dix ans au moins. Non, il s’agit d’un comportement dont je suis parfois aussi coupable et que plusieurs d’entre vous ont aussi : oublier de redémarrer au besoin. Petit billet « hors-planning » donc pour expliquer de quoi il est question.

On râle contre Microsoft parce qu’on doit redémarrer Windows une fois par mois après le patch Tuesday (deuxième mardi de chaque mois), après les mises à jour, quand ce n’est pas plus à l’occasion d’une faille 0-day. Mais si les systèmes Linux sont moins sujets à ce comportement, ils n’en sont pas exempt pour autant.

En effet, Comme pour Windows, les programmes qui sont lancés sur une machine sont des copies en mémoire vive de ceux installés sur le disque. Prenons l’exemple d’un serveur Web, ou d’un serveur MySQL : tant qu’ils sont en cours d’exécution, c’est la version « en RAM » qui fonctionne et qui sert le ou les sites Web. Si une mise à jour sort pour ces composants, c’est la version sur disque qui est mise à jour. Et tant qu’on ne les redémarre pas, ce qui oblige à les relire depuis le disque, c’est la version vulnérable qui continuera alors à fonctionner (sous Debian, il se charge de redémarrer certains services pour vous après leur mise à jour) ! Ceci vaut aussi bien pour les services système que pour des logiciels aussi « simples » que Firefox : lors de la mise à jour, il se ferme, installe la nouvelle version, et redémarre. Enfin ça c’est pour la version Windows, sous Linux, c’est à vous de fermer/relancer le programme.

Dans le cadre de GHOST, qui implique une mise à jour de la libc, ce sont tous les composants qui en dépendent qui nécessitent un redémarrage. Parmi eux, le plus important : init, qui est le tout premier, dont le travail est de démarrer les autres. Redémarrer init impliquer de redémarrer tous les autres processus. Le plus simple est donc de redémarrer tout le système. Ceci vaut évidemment pour les mises à jour du noyau lui-même et ce de manière générale (petite pensée pour les BSD).

Si je le rappelle, c’est que même moi, il m’arrive parfois de passer outre un tel redémarrage, parce que je fais la mise à jour en pleine journée et que je ne me vois pas couper la chique à mes utilisateurs, même s’ils ne sont pas si nombreux. Et je ne dois pas être le seul. On a tous la hantise que les gens disparaissent à la moindre interruption de service, la fidélité étant un concept assez volatile sur Internet (en dehors des drogués à Facebook). Mais il n’est pas non plus question de jouer au jeu du kikalaplugross, avec le plus gros uptime : une passoire endurante reste une passoire. Julien Hommet l’a très bien rappelé sur son nouveau site, ce qu’il peut en coûter n’en vaut pas la chandelle.

Je sais que chaque infrastructure est différente, et donc le temps de mise hors-ligne n’est pas facile à déterminer ou encaisser (certains gagnent leur vie avec, et la moindre minute peut coûter cher, comme les victimes d’attaques DDoS en témoignent). Il ne tient donc qu’à vous de réfléchir aux bénéfices et risques que vous courez. À l’ère de la virtualisation et du cloud, certains seront capables de mettre à jour de manière presque transparente, sans interruption. Dans tous les cas, un redémarrage est nécessaire. Et pourquoi pas une remise en question de votre infrastructure pour la rendre plus souple et mieux gérer ces mises à jour ? Et vous, vous faites comment actuellement pour gérer ces mises à jour ?