Re: Faille critique découverte dans GLIBC
Ah, au fait, petite question. Après les commandes ci-dessus,
faut-il que je fasse un reboot ?
J'ajouterais, dans un souci d'échange et de discussion, que le reboot ne
me semble pas si important que cela (aie, je prend un risque en disant
cela), pourquoi?
Les fichiers qui correspondent aux processus exécutés sur un système
Linux sont protégés en écriture, petit rappel:
$ cat >> read_bloquant.c << FIN
# include <stdio.h>
int main (void)
{
read (0, NULL, sizeof(int));
/* En gros on exécute un appel système bloquant, on lit depuis l'entrée
standard, en général la console, NULL parce qu'on s'en fout du résultat
et le sizeof parce que ça fait plus cool qu'un 4 ou un 8 (et portable).
Donc tant qu'on n'entre pas un caractère (dac, un nombre (cela dit,
c'est du C, c'est pareil pour "lui", chez moi il en mange 4 donc int = 4
octets, moins si caractère en dehors ascii et si console en UTF-8 par
ex) et qu'on n'appuie pas sur Entrée le programme attend */
exit (0);
}
FIN
Désolé si ça fait un peu cours et pour tout ceux qui savent déjà tout ça!
Donc on compile et on exécute:
$ gcc read_bloquant.c -o read_bloquant
$ ./read_bloquant
Ça y est, le processus attend.
Sur une autre console :
$ kate read_bloquant
(ou gedit, mousepad etc.)
Impossible de sauvegarder les modifs (on peut avec vim, allez savoir!).
Et possible lorsque le programme n'est pas exécuté.
Lorsque j'ai mis à jour la libc sur ma wheezy je n'ai pas eu de souci
particulier, virtualbox (qui n'était pas en exécution) s'est recompilé
son module, 2-3 petits trucs et c'était bon.
Ce que j'en conclus, c'est que sur mon système la mise à jour n'a
remplacé aucun fichier en cours d'utilisation donc que le reboot n'est
peut-être pas indispensable.
Toutefois, juste pour être sûr et si j'étais admin je viderais tout ce
qui est buffer/cache avant la mise à jour et également après tant qu'à
faire:
# echo 3 > /proc/sys/vm/drop_caches
Et si ça swappe (c'est pas dit avec tout ces ordi à 8+ Gb de ram), je
tuerais quelque processus après avoir exécuté:
# echo 0 > /proc/sys/vm/swappiness
Attention tout de même à ne pas exécuter cela sur un pc avec très peu de
mémoire mais de toute façon je suis même pas sûr que cette dernière
ligne aurait de l'effet dans ce cas.
Une dernière chose:
Un programme peut être lié à une ABI de la libc de façon statique ou
dynamique.
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).
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).
Voilà pour mes petites réflexion, s'il y a des erreurs de logique merci
de me corriger.
Cordialement/Bises...
--
mrr
Reply to: