Le 22 août avait apporté des mises à jours de sécurité sur la libxml2 qui potentiellement pouvait allouer de la mémoire jusqu'à exhaustion de la mémoire du système [1]. Il y a donc eu une correction de bug de la libxml2 de façon à ce que l'allocation mémoire soit faite correctement.
L'incidence de cette correction de bug est une cessation de fonctionnement de toutes les applications qui utilisent la librsvg pour le rendu de graphisme vectoriel SVG. Ainsi, si vous utilisez Gnome avec un thème vectoriel, vous n'aurez même plus accès a votre session. Si ce n'est pas le cas et que vous démarrez le gestionnaire de thème, vous allez voir que celui-ci est freezé (problème de verrouillage silencieux).
En fait, il doit y avoir un bug dans la bibliothèque librsgv qui était masqué par le bug de la libxml2 [2]. Comme quoi :
- Un bug peut en cacher un autre (TM)
- Le mieux n'est pas forcément l'ami du bien
Pour corriger, le plus simple est probablement de "downgrader" provisoirement le paquet libxml2 pour la version précédente (libxml2_2.6.27.dfsg-2_[ARCH].deb) qui avec un peu de chance se trouve encore dans votre répertoire /var/cache/apt/archives/
Bon retour à la normale.
[1] http://www.debian.org/security/2008/dsa-1631
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496125
# C'est mon choix
Posté par pampryl . Évalué à 3.
[...]
Pour corriger, le plus simple est probablement de "downgrader" provisoirement le paquet libxml2 pour la version précédente (libxml2_2.6.27.dfsg-2_[ARCH].deb) qui avec un peu de chance se trouve encore dans votre répertoire /var/cache/apt/archives/
Donc en gros tu proposes de laisser ouvert un défaut de sécurité et de réparer ainsi un problème graphique?
... pas convaincu que c'est le meilleur choix.
[^] # Re: C'est mon choix
Posté par e-t172 (site web personnel) . Évalué à 10.
Le choix est vite fait.
[^] # Re: C'est mon choix
Posté par pampryl . Évalué à 0.
[^] # Re: C'est mon choix
Posté par e-t172 (site web personnel) . Évalué à 7.
La faille a les conséquences suivantes : une application susceptible de parser du code XML qui n'est pas de confiance (l'exemple qui vient à l'esprit est celui du navigateur web), si elle rencontre un code XML malicieux, va freezer et bouffer toutes les ressources CPU et RAM.
Mais le système ne va pas devenir inutilisable. Un seul processus ne peut pas à lui tout seul mettre à genoux le système entier, sinon c'est que tu as un problème beaucoup plus gros que celui qu'on traite ici...
Donc si le navigateur web se fait attaquer, il suffit à l'utilisateur de le killer, puis de le relancer en prenant soin de ne pas revenir à l'endroit où il y a ce code XML malveillant (même Madame Michu peut arriver à la conclusion "ce site fait planter mon navigateur"). Au final, la gêne est minime. D'autant plus que ça m'étonnerait que beaucoup de gens se fassent attaquer : un DoS limité sur un navigateur, à part des blagues puériles, ça a un intérêt discutable pour l'attaquant...
A l'opposé, si tu mets à jour libxml, tu t'exposes un autre bug nettement plus grave en comparaison, parce qu'il est systématique et qu'il empêche le fonctionnement de certaines applications, voire du bureau Gnome dans son intégralité dans certaines conditions. Là, madame Michu ne sait pas quoi faire, et l'utilisateur averti va au moins être passablement énervé.
Donc je persiste, il est plus avantageux de revenir à la version vulnérable que de rester avec la version patchée mais buggée.
[^] # Re: C'est mon choix
Posté par Moonz . Évalué à 2.
:(){:|:};:
(bon, d'accord, c'est pas à strictement parler un seul processus)
[^] # Re: C'est mon choix
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 1.
"Un seul processus ne peut pas à lui tout seul mettre à genoux le système entier, sinon c'est que tu as un problème beaucoup plus gros que celui qu'on traite ici..."
Tout ça pour dire que cela se configure, taille max en ram, nombre de forks... Avec ulimit notamment. http://en.wikipedia.org/wiki/Fork_bomb#Prevention
[^] # Re: C'est mon choix
Posté par Thibaut (site web personnel) . Évalué à 6.
La mise à jour de libxml2 a ajouté un membre à la structure xmlEntity, du coup librsvg2 n'alloue plus assez de place.
Une solution un peu meilleure que de downgrader en attendant la correction de librsvg2, c'est de le recompiler, mais ça prends plus de temps que de downgrader libxml2.
[^] # Re: C'est mon choix
Posté par yellowiscool . Évalué à 4.
La taille en mémoire d'une structure, c'est rien du tout…
Envoyé depuis mon lapin.
[^] # Re: C'est mon choix
Posté par ステファン . Évalué à 4.
Je crois que tout a été dit par ailleur sur les mérites respectifs des différentes solutions. Le mot important est que c'est une solution certes paliative mais provisoire en attendant que la version corrigée de la librsvg entre dans Debian.
Mais j'ai passé 2 heures et demi hier devant mon ordinateur en me demandant pourquoi ma session ne voulait pas démarer, avec qui plus est aucun indice dans les logs. J'avais commencé par suspecter un problème matériel, puis, l'ayant écarté, je me suis demandé ce qui avait changé récemment. Je me suis alors souvenu de la mise à jour de la libxml2 de la veille. J'ai découvers le pot au roses en consultant les rapports de bugs pour la bibliothèque en question.
Voilà, peut être que ce journal évitera quelques frayeurs et/ou heures de galères à certains ; dans ce cas il aura rempli son rôle.
# XML ?
Posté par dinomasque . Évalué à 10.
Epuiser la mémoire du système n'est-il pas pourtant le but premier d'XML ?
BeOS le faisait il y a 20 ans !
[^] # Re: XML ?
Posté par mats . Évalué à 10.
[^] # Re: XML ?
Posté par Raphaël G. (site web personnel) . Évalué à 3.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Tiens...
Posté par Nerdiland de Fesseps . Évalué à 5.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.