Re: Faille critique découverte dans GLIBC
Salut Seb,
Si c'est dynamique comme l'appel à read ci-dessus (on peux voir entre autres
grâce à strace que c'est /lib/i386-linux-gnu/i686/cmov/libc.so.6 qui est
appelé chez moi), aucun problème tant que le programme utilise un cache bien
mis à jour (ce qui est normalement le cas mais c'est t'on jamais d'où les 2
dernières commandes).
Oups, ça c'est de l'erreur de syntaxe (de logique aussi si on veut):
s/c'est/sait
Dans ce cas, il me semble (et je peux donc me tromper, dans ce cas, il faudra me
corriger) que la bibliothèque dynamique est chargée au démarrage du programme.
Chacun des appels système sera donc fait selon la version installée à ce
moment-là. Si on met à jour la bibliothèque en cours d'exécution, le programme
ne profitera donc pas des corrections.
Je vois, au 1er appel la librairie serait mappée en mémoire puis en
quelque sorte détachée de sa source, à savoir le fichier sur le disque.
Tu dois avoir raison, cela aurait également le mérite d'expliquer ma
1ère remarque, l'accès en écriture sur un fichier en cours d'exécution
(bon, processus, dac mais on se comprend).
Et ça expliquerait aussi le résultat d'André (message suivant).
Par contre, ce qui me gène un peu c'est que cela signifierait que chaque
processus en cours d'exécution aurait sa propre copie en mémoire.
Ou il y a une autre possibilité de comprendre ta phrase qui me convient
mieux, c'est qu'à chaque fois qu'une bibliothèque partagée est appelée
pour la *1ère* fois, elle serait mappée dans l'espace virtuel pour tout
le monde jusqu'à ce qu'il n'y ait plus aucun processus qui l'utilise et
alors elle serait "déchargée".
De toute façon je vais essayer genre pour le fun =>
- créer un .so qui affiche "Version initiale".
- lancer un programme qui appelle .so puis qui se bloque.
- modifier le .so pour qu'il affiche "Version modifiée".
- reprendre l'exécution.
Et tant qu'à faire, lancer le programme 2 fois, avant et après modif.
Si je fais ça rapidement je vous poste le résultat.
Au passage, si quelqu'un pouvait m'expliquer le comportement de vim (en
une phrase, je sais que c'est pas le sujet initial)?
Si c'est statique (avec la libc ce doit être rare voire inexistant, j'ai pas
vérifié), alors là un reboot n'y fera rien, il faudra recompiler le paquet,
c'est d'ailleurs un des principaux désavantage des librairies statiques
(avec la quantité d'espace mémoire utilisée, l'avantage étant un programme
très légèrement plus rapide).
Oui, pour les liens statiques, aucun impact sans passer par une recompilation.
C'est donc hors-champ.
Un autre avantage des liens statiques, c'est le coté transportable du binaire,
tu peux le lancer sur une machine qui ne dispose pas de toutes les bibliothèques
nécessaires (puisque le programme « embarque » tous les bouts de bibliothèques
dont il a besoin).
Exact, bien vu!
Je crois au passage que c'est bien plus utilisé sur Windows, ça règle
les problèmes de versions et on sait vraiment avec quoi on travaille.
Linux est plus ambitieux mais parallèlement (et on en parlait récemment
sur un autre thread) cela augmente la complexité du système de dépendances.
Seb
@ Sébastien (message précédent, je vais pas alourdir le fil de 3
messages juste pour ça): je crois avoir bien précisé que je n'étais pas
sûr de moi et à aucun moment j'ai déconseillé le reboot (qui est
manifestement utile d'après les réponses des uns et des autres).
Update:
- En réfléchissant aux autres librairies que fournit la glibc j'ai
oublié de penser que c'est elle même qui fournit le chargeur de lien
dynamique (via /lib/i386-linux-gnu/ld-2.13.so sur mon système) qui est
lui même un objet partagé. Bon, même combat, il faut bien d'une façon ou
d'une autre que le nouveau entre en action. Et d'une façon ou d'une
autre c'est l'ancien qui charge le nouveau afin que ce dernier l'écrase.
Ouais, du coup, _reboot_ ça me parle plus là.
- De la page man de ld.so et à la section BOGUES:
"Actuellement, ld.so ne peut pas enlever un lien existant pour chercher
des bibliothèques compatibles ou plus récentes."
Ça revient à ce que tu disais Seb.
Allez, bonne nuit tout le monde.
--
mrr
Reply to: