subject:"Faille critique découverte dans GLIBC"

On 2015-01-28 23:16:48 +0100, Bernard Isambert wrote:
 Le 28/01/2015 20:59, Philippe Deleval a écrit :
 C'est une blague? A mon avis, tout programmeur utilisant la fonction de
 bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où
 il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s,
 ct, n), le petit n fait la différence.

 Et ceux qui créé la fonction strcpy sont des criminels qui devraient être
 guillotinés sur le champ. Heureusement, Zorro est arrivé et a sauvé
 l'informatique...

Faut voir l'historique: strcpy date de l'origine du langage C,
à un temps où on ne se préoccupait pas trop des problèmes de
sécurité.

Maintenant, la fonction strcpy devrait peut-être prendre le même
chemin que gets.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150129103012.gb8...@xvii.vinc17.org

Re: Faille critique découverte dans GLIBC

On 2015-01-28 20:59:50 +0100, Philippe Deleval wrote:
 C'est une blague? A mon avis, tout programmeur utilisant la fonction de
 bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où il
 travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s, ct, n),
 le petit n fait la différence.

Enfin, strncpy n'est pas vraiment safe non plus. Un problème est
que si le n est trop petit, le buffer n'est plus forcément terminé
par un \0, ce qui peut être en soi un trou de sécurité: si on
copie la chaîne contenue dans le buffer, cela peut donc copier
des données au-delà du buffer, et on se retrouve donc avec des
bugs du type heartbleed. La vraie solution est d'avoir une fonction
qui fait un abort() quand le n est trop petit... et si le serveur
est critique, on n'écrit pas en C.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150129105433.gc8...@xvii.vinc17.org

Re: Faille critique découverte dans GLIBC

2015-01-29 Par sujet mrr


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

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54ca32ea$0$3190$426a7...@news.free.fr

Re: Faille critique découverte dans GLIBC

2015-01-29 Par sujet Dominique Asselineau

mrr wrote on Thu, Jan 29, 2015 at 02:17:32PM +0100
 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?

Il faut juste penser à prévenir les utilisateurs suffisamment à
l'avance pour éviter de leur casser la baraque.

Dominique

 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
 
 -- 
 Lisez la FAQ de la liste avant de poser une question :
 http://wiki.debian.org/fr/FrenchLists
 
 Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
 vers debian-user-french-requ...@lists.debian.org
 En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
 Archive: https://lists.debian.org/54ca32ea$0$3190$426a7...@news.free.fr
 

-- 

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150129134917.gb11...@telecom-paristech.fr

Re: Faille critique découverte dans GLIBC

2015-01-29 Par sujet Sébastien NOBILI

Bonjour,

J'ai bien aimé le passage en C, ça m'a rappelé de (trop) vieux souvenirs ;-)


Le jeudi 29 janvier 2015 à 14:17, mrr a écrit :
 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).

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.

 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).

Seb

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150129140619.gb13...@sebian.nob900.homeip.net

Re: Faille critique découverte dans GLIBC

2015-01-29 Par sujet andre_debian

On Thursday 29 January 2015 14:17:32 mrr wrote:
  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:  [cut]

Sous Wheezy, j'avais bien updaté glibc6,
recompilé ghosttest.c et avais : Vulnerable

J'ai fait un reboot = Not vulnerable.

André

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/201501291521.26865.andre_deb...@numericable.fr

Re: Faille critique découverte dans GLIBC

2015-01-29 Par sujet Philippe Deleval


Le 28/01/2015 23:16, Bernard Isambert a écrit :

Le 28/01/2015 20:59, Philippe Deleval a écrit :

Bonjour à tous

C'est une blague? A mon avis, tout programmeur utilisant la fonction de
bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où
il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s,
ct, n), le petit n fait la différence.

Cordialement


Philippe Deleval

Et ceux qui créé la fonction strcpy sont des criminels qui devraient 
être guillotinés sur le champ. Heureusement, Zorro est arrivé et a 
sauvé l'informatique...


Ceux qui ont créé strcpy n'étaient sans doute pas conscients que le 
système qu'ils écrivaient et le langage qu'ils concevaient auraient une 
telle fortune, avaient-ils prévu Internet? Après tout, ma source sur C 
est signée Kernighan-Ritchie. C'est l'expérience qui a dégagé ce qui 
était plus ou moins bon. strcpy peut encore être utilisé sans danger par 
un programmeur qui sait ce qu'il fait et maîtrise la longiueur des 
chaînes qu'il manipule, je pnese que c'était la vocation première. Mais 
lire par strcpy une chaîne qui vient d'ailleurs, c'est un risque notoire!


Cordialement

Philippe Deleval (et non zorro, je ne sais pas monter à cheval!)

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54ca9395.2070...@wanadoo.fr

Re: Faille critique découverte dans GLIBC

2015-01-29 Par sujet mrr


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

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54ca99a9$0$3295$426a7...@news.free.fr

Re: Faille critique découverte dans GLIBC

2015-01-29 Par sujet mrr


On 29/01/2015 21:10, Philippe Deleval wrote:

Le 28/01/2015 23:16, Bernard Isambert a écrit :

Le 28/01/2015 20:59, Philippe Deleval a écrit :

Bonjour à tous

C'est une blague? A mon avis, tout programmeur utilisant la fonction de
bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où
il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s,
ct, n), le petit n fait la différence.

Cordialement


Philippe Deleval


Et ceux qui créé la fonction strcpy sont des criminels qui devraient
être guillotinés sur le champ. Heureusement, Zorro est arrivé et a
sauvé l'informatique...


Ceux qui ont créé strcpy n'étaient sans doute pas conscients que le
système qu'ils écrivaient et le langage qu'ils concevaient auraient une
telle fortune, avaient-ils prévu Internet? Après tout, ma source sur C
est signée Kernighan-Ritchie. C'est l'expérience qui a dégagé ce qui
était plus ou moins bon. strcpy peut encore être utilisé sans danger par
un programmeur qui sait ce qu'il fait et maîtrise la longiueur des
chaînes qu'il manipule, je pnese que c'était la vocation première. Mais
lire par strcpy une chaîne qui vient d'ailleurs, c'est un risque notoire!


Un des trucs qui me plaît dans linux (ok, la libc c'est pas que linux, 
je sais) donc ce qui me plait c'est la liberté qu'on te donne, y compris 
la liberté de faire une bêtise.


Essayez (ou pas en fait) le fameux rm -rf / et vous aurez droit à un 
gentil message qui vous préviendra que c'est dangereux.


Je suis nostalgique, avant on pouvait détruire son système en paix :)


Cordialement

Philippe Deleval (et non zorro, je ne sais pas monter à cheval!)




--
--
mrr

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54caa1da$0$3066$426a7...@news.free.fr

Re: Faille critique découverte dans GLIBC

2015-01-29 Par sujet Pascal Hambourg

mrr a écrit :
 
 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.

Et c'est bien pour cela qu'il faut redémarrer les processus utilisant un
exécutable (bibliothèque ou autre) mis à jour.

 Je vois, au 1er appel la librairie serait mappée en mémoire puis en 

Oui.

 quelque sorte détachée de sa source, à savoir le fichier sur le disque.

Non, elle reste liée au fichier. C'est le principe du mapping. Même
chose pour l'exécutable d'un programme qui tourne.

 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.

Non, pas forcément, tant que la copie n'est pas modifiée. Ensuite seules
les pages éventuellement modifiées par un processus font l'objet d'une
copie séparée dans la mémoire virtuelle de ce processus.

 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.

Il y a de ça. Chaque ouverture d'un fichier compte pour un lien vers
l'inode correspondant, au même titre que les liens durs dans les
répertoires. La mise à jour fait pointer le nom du fichier vers un
nouvel inode qui contient la nouvelle version du fichier, mais l'inode
originel reste présent tant qu'il reste des liens, donc tant qu'il n'est
pas fermé par les processus qui l'ont ouvert.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54caa225.5040...@plouf.fr.eu.org

Re: Faille critique découverte dans GLIBC

2015-01-29 Par sujet Bernard Isambert



trolldi (en avance)

Le 29/01/2015 21:09, Philippe Deleval a écrit :

Le 28/01/2015 20:59, Philippe Deleval a écrit :

C'est une blague? A mon avis, tout programmeur utilisant la fonction de
bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où
il travaille pour faute grave!



strcpy peut encore être utilisé sans danger par
un programmeur qui sait ce qu'il fait et maîtrise la longiueur des
chaînes qu'il manipule,


Conclusion évidente : vous voulez renvoyer pour faute grave un 
programmeur qui sait ce qu'il fait !


Excusez-moi, je n'ai pas pu m'empêcher de faire le rapprochement entre 
vos deux phrases ! C'était trop tentant !


/trolldi


--
Bernard.
20 ans d'utilisation de Debian. Comme le temps passe...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54caab9e.3090...@taranig.net

Re: Faille critique découverte dans GLIBC

On 2015-01-30 01:45:47 +0100, Vincent Lefevre wrote:
 On 2015-01-30 00:30:29 +0100, Francois Lafont wrote:
  Si je comprends bien d'un côté cette zone n'est plus accessible via
  l'arborescence du filesystem car l'ancien inode n'existe plus. Du
  coup, cette zone du disque serait libre en quelques sortes ?
 
 Non, l'ancien inode existe toujours (je suppose qu'un processus
 qui a le fichier ouvert peut toujours faire un fstat sur le
 descripteur de fichier pour obtenir le numéro d'inode).

Exemple avec un petit script zsh:

zmodload zsh/stat
echo foo  tmp-file
stat tmp-file | grep -E '^(inode|nlink) '
exec  tmp-file
stat -f 0 | grep -E '^(inode|nlink) '
rm tmp-file
stat -f 0 | grep -E '^(inode|nlink) '
cat

J'obtiens:

inode   4940899
nlink   1
inode   4940899
nlink   1
inode   4940899
nlink   0
foo

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150130005530.ga16...@xvii.vinc17.org

Re: Faille critique découverte dans GLIBC

On 2015-01-30 00:30:29 +0100, Francois Lafont wrote:
 Le 29/01/2015 22:12, Pascal Hambourg a écrit :
  Il y a de ça. Chaque ouverture d'un fichier compte pour un lien vers
  l'inode correspondant, au même titre que les liens durs dans les
  répertoires. La mise à jour fait pointer le nom du fichier vers un
  nouvel inode 
 
 Tu parles bien de la mis à jour d'une lib ?
 Dans ce cas, je ne comprends pas trop ce que tu veux dire par nouvel inode.
 Par exemple, j'ai ça :
 
 ~$ touch /tmp/foo.so
 ~$ touch /tmp/foo.so.new-version
 
 ~$ ls -i /tmp/foo.so*
 523294 /tmp/foo.so  523295 /tmp/foo.so.new-version
 
 # Je considère la commande ci-dessous comme une màj du fichier foo.so
 ~$ cp /tmp/foo.so.new-version /tmp/foo.so
 
 # Et je constate que le numéro d'inode de foo.so n'a pas bougé ?
 ~$ ls -i /tmp/foo.so*
 523294 /tmp/foo.so  523295 /tmp/foo.so.new-version

Mais une mise à jour ne fait pas un cp. Un cp va modifier un
fichier si la destination existe, pas créer un nouveau fichier.

 Du coup, j'ai pas dû comprendre quelque chose dans ta phrase.
 
  qui contient la nouvelle version du fichier, mais l'inode
  originel reste présent 
 
 Présent où ça ? Dans les « attributs » des processus en cours ?

Présent sur le disque (et référencé par les processus).

  tant qu'il reste des liens, donc tant qu'il n'est
  pas fermé par les processus qui l'ont ouvert.
 
 Mais durant cette période transitoire où il reste encore des
 processus qui ont ouvert un fichier situé sur une zone A du
 disque, zone pointée par cet « ancien » inode, qu'en est-il
 de cette zone A du disque ? Est-elle disponible ou non ?

Non, elle n'est toujours pas disponible. Le fichier existe
toujours. Cf la page man unlink(2):

  unlink() deletes a name from the filesystem.  If that name was the last
  link to a file and no processes have the file open, the file is deleted
  and the space it was using is made available for reuse.

  If  the  name  was the last link to a file but any processes still have
  the file open, the file will remain in existence until  the  last  file
  descriptor referring to it is closed.

  If the name referred to a symbolic link, the link is removed.

 Si je comprends bien d'un côté cette zone n'est plus accessible via
 l'arborescence du filesystem car l'ancien inode n'existe plus. Du
 coup, cette zone du disque serait libre en quelques sortes ?

Non, l'ancien inode existe toujours (je suppose qu'un processus
qui a le fichier ouvert peut toujours faire un fstat sur le
descripteur de fichier pour obtenir le numéro d'inode).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150130004547.gb14...@xvii.vinc17.org

Re: Faille critique découverte dans GLIBC

2015-01-29 Par sujet Vincent Bernat

 ❦ 28 janvier 2015 20:59 +0100, Philippe Deleval philippe.dele...@wanadoo.fr :

 C'est une blague? A mon avis, tout programmeur utilisant la fonction
 de bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la
 boîte où il travaille pour faute grave! Il y a à côté strncpy(char
 *strncpy (s, ct, n), le petit n fait la différence.

Faire strncpy(hostname, name, strlen(name) + 1) est tout à fait
inutile. Le problème n'est pas le strcpy, mais la taille allouée pour la
structure incluant hostname qui était trop petite.
-- 
If you tell the truth you don't have to remember anything.
-- Mark Twain


signature.asc
Description: PGP signature

Re: Faille critique découverte dans GLIBC

2015-01-29 Par sujet Francois Lafont

On sort un peu (beaucoup) du sujet de cette liste mais
ça m'intéresse alors du coup j'aurais quelques questions
si c'est possible.

Le 29/01/2015 22:12, Pascal Hambourg a écrit :

 Il y a de ça. Chaque ouverture d'un fichier compte pour un lien vers
 l'inode correspondant, au même titre que les liens durs dans les
 répertoires. La mise à jour fait pointer le nom du fichier vers un
 nouvel inode 

Tu parles bien de la mis à jour d'une lib ?
Dans ce cas, je ne comprends pas trop ce que tu veux dire par nouvel inode.
Par exemple, j'ai ça :

~$ touch /tmp/foo.so
~$ touch /tmp/foo.so.new-version

~$ ls -i /tmp/foo.so*
523294 /tmp/foo.so  523295 /tmp/foo.so.new-version

# Je considère la commande ci-dessous comme une màj du fichier foo.so
~$ cp /tmp/foo.so.new-version /tmp/foo.so

# Et je constate que le numéro d'inode de foo.so n'a pas bougé ?
~$ ls -i /tmp/foo.so*
523294 /tmp/foo.so  523295 /tmp/foo.so.new-version

Du coup, j'ai pas dû comprendre quelque chose dans ta phrase.

 qui contient la nouvelle version du fichier, mais l'inode
 originel reste présent 

Présent où ça ? Dans les « attributs » des processus en cours ?
(Pour le terme « attributs », désolé je ne connais pas le bon vocabulaire.)

 tant qu'il reste des liens, donc tant qu'il n'est
 pas fermé par les processus qui l'ont ouvert.

Mais durant cette période transitoire où il reste encore des
processus qui ont ouvert un fichier situé sur une zone A du
disque, zone pointée par cet « ancien » inode, qu'en est-il
de cette zone A du disque ? Est-elle disponible ou non ?

Si je comprends bien d'un côté cette zone n'est plus accessible via
l'arborescence du filesystem car l'ancien inode n'existe plus. Du
coup, cette zone du disque serait libre en quelques sortes ?

Mais d'un autre côté, on peut imaginer que le système se doit
d'interdire toute écriture au niveau de cette zone du disque
sans quoi les processus ouverts pourraient lire alors absolument
n'importe quoi au niveau de cette zone et donc finalement cette
zone mémoire n'est donc pas complètement disponible encore ?

-- 
François Lafont

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/maefqg$o2t$1...@ger.gmane.org

Re: Faille critique découverte dans GLIBC

2015-01-28 Par sujet Sébastien NOBILI

Bonjour,

Le mercredi 28 janvier 2015 à 14:43, Francois Lafont a écrit :
 Le 28/01/2015 14:34, Francois Lafont a écrit :
  echo deb http://http.debian.net/debian/ squeeze-lts main contrib non-free 
   /etc/apt/sources.list.d/squeeze-lts.list
  apt-get update
  apt-get upgrade
 
 Ah, au fait, petite question. Après les commandes ci-dessus,
 faut-il que je fasse un reboot ?
 
 Si j'ai bien compris, si un daemon dépend d'une lib, il faut
 redémarrer le-dit daemon après la mise à jour de la-dite lib.
 Seulement j'ai cru comprendre que globalement, quasiment tous
 les daemons (sous Debian) dépendent in fine de la glibc et
 qu'au final un reboot est globalement nécessaire. Bref, j'ai
 lu je ne sais plus où que l'idée selon laquelle seule la
 màj du noyau nécessitait un reboot était inexacte et que le
 reboot était également nécessaire pour la màj de la glic.
 
 Bref, ce serait possible d'avoir un avis d'expert sur la question ? ;)
 Merci d'avance.

Loin de moi l'idée de me considérer comme tel…

Il y a justement une discussion à ce sujet en ce moment sur debian-security [1].
Tous les programmes qui utilisent de la bibliothèque mise à jour doivent être
redémarrés. On doit donc redémarrer les services qui l'utilisent.

Dans le cas de la libc, ça devient problématique car _tous_ les programmes du
système l'utilisent. Il faut donc redémarrer _tous_ les programmes actuellement
en fonctionnement.

Deux approches :
- tu les identifies un par un et tu les redémarres un par un (et tu ne fais
  rien d'autre de ta journée);
- tu rebootes et c'est réglé en quelques minutes.

1: https://lists.debian.org/debian-security/2015/01/msg00035.html

Seb

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150128135116.gd13...@sebian.nob900.homeip.net

Re: Faille critique découverte dans GLIBC

Le 28/01/2015 14:19, andre_deb...@numericable.fr a écrit :

 Non, seul squeeze-lts évolue encore.
 
 Ok, merci pour la réponse.

 En même temps ma question était sans doute un peu bête, car le dépôt LTS
 perdrait tout son sens si le dépôt squeeze évoluait encore. ;)
 
 Pourrait-on avoir le mode opératoire sous Debian,

Sous Squeeze ?
Et bien comme indiqué ici par exemple : https://wiki.debian.org/fr/LTS/Using

Perso, je ne me suis pas embêté :

echo deb http://http.debian.net/debian/ squeeze-lts main contrib non-free  
/etc/apt/sources.list.d/squeeze-lts.list
apt-get update
apt-get upgrade

 sans faire ce que propose ce site :
 www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/#GHOSTVulnerabilityCheck
 à savoir # apt-get dist-upgrade

Perso, j'avoue que je l'utilise quotidiennement cette commande
et je n'ai jamais eu de souci. Ai-je tort ?

Si j'ai bien compris ce que dit la page man, avec upgrade aucune
chance de voir un paquet supprimé etc. alors qu'avec dist-upgrade
ça peut arriver.

Évidemment si je mets des dépôts de la distribution n+1 dans les
sources.list alors là un dist-upgrade peut faire des dégats mais
sinon j'ai l'impression que dans 99% des cas un upgrade et un
dist-upgrade font au final la même chose.

De toute façon, si tu veux être prudent, tu fais un upgrade et
puis voilà (en plus même avec un dist-upgrade, tu jettes un œil
sur les modifications que souhaite faire la commande avant de
confirmer).

-- 
François Lafont

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/maaohh$fco$1...@ger.gmane.org

Re: Faille critique découverte dans GLIBC

2015-01-28 Par sujet Sébastien NOBILI

Le mercredi 28 janvier 2015 à 14:34, Francois Lafont a écrit :
Le 28/01/2015 14:19, andre_deb...@numericable.fr a écrit :
sans faire ce que propose ce site :
www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/#GHOSTVulnerabilityCheck
à savoir # apt-get dist-upgrade

Perso, j'avoue que je l'utilise quotidiennement cette commande
et je n'ai jamais eu de souci. Ai-je tort ?

Je l'utilise également au quotidien (plutôt au gré des mises à jour qui
arrivent) et sans aucun souci depuis plusieurs années.

Si j'ai bien compris ce que dit la page man, avec upgrade aucune
chance de voir un paquet supprimé etc. alors qu'avec dist-upgrade
ça peut arriver.

C'est exactement ça, « upgrade » ne fera que ce qui ne nécessite aucun ajout ni
aucune suppression alors que « dist-upgrade » mettra tout à niveau même si ça
nécessite ajout ou suppression.

Évidemment si je mets des dépôts de la distribution n+1 dans les
sources.list alors là un dist-upgrade peut faire des dégats mais
sinon j'ai l'impression que dans 99% des cas un upgrade et un
dist-upgrade font au final la même chose.

C'est exactement ça.

Attention toutefois.

On peut référencer la branche Debian dans le sources.list par son nom
(« squeeze », « wheezy », « jessie ») ou bien par son type (« stable »,
« testing »).

Si on référence le type, alors un « dist-upgrade » conduit au passage d'une
branche à la suivante dès la publication.

Si on veut vraiment maîtriser son système, mieux vaut référencer la branche par
son nom.

Seb

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive:
https://lists.debian.org/20150128135530.ge13...@sebian.nob900.homeip.net

Re: Faille critique découverte dans GLIBC

Le 28/01/2015 14:55, Sébastien NOBILI a écrit :

 Attention toutefois.
 
 On peut référencer la branche Debian dans le sources.list par son nom
 (« squeeze », « wheezy », « jessie ») ou bien par son type (« stable »,
 « testing »).
 
 Si on référence le type, alors un « dist-upgrade » conduit au passage d'une
 branche à la suivante dès la publication.
 
 Si on veut vraiment maîtriser son système, mieux vaut référencer la branche 
 par
 son nom.

Oh oui, perso j'ai toujours mis le nom sans penser au départ à ce
que tu décris mais je connais des gens qui se sont pris un upgrade
de distribution dans la figure comme ça. :)

Merci pour ta réponse.

-- 
François Lafont

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/maaqln$ksa$1...@ger.gmane.org

Re: Faille critique découverte dans GLIBC

Le 28/01/2015 14:45, andre_deb...@numericable.fr a écrit :

 Je suis sous Wheezy...

Et bien tu mets à jour ta Wheezy de manière on ne peut plus
classique :

apt-get update  apt-get upgrade

Je vois pas où est le problème.

-- 
François Lafont

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/maapf8$ofv$2...@ger.gmane.org

Re: Faille critique découverte dans GLIBC

2015-01-28 Par sujet Nicolas KOWALSKI

On Wed, Jan 28, 2015 at 02:43:54PM +0100, Francois Lafont wrote:
 Ah, au fait, petite question. Après les commandes ci-dessus,
 faut-il que je fasse un reboot ?

La commande checkrestart (paquet debian-goodies) permet de savoir 
facilement quels sont les processus à relancer après une mise-à-jour 
classique.

A contrario, une m-a-j de la libc est tellement impactante (tout ou 
presque doit être relancé) que je ne me pose plus la question : c'est 
reboot direct après coup.

-- 
Nicolas

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150128135433.ga2...@petole.demisel.net

Re: Faille critique découverte dans GLIBC

2015-01-28 Par sujet andre_debian

On Wednesday 28 January 2015 13:41:22 Francois Lafont wrote:
 Le 28/01/2015 12:47, Bernard Isambert a écrit :
  Est-ce qu'il y a une chance que le correctif soit tout simplement
  disponible sur les dépôts squeeze « normaux » ?

  Non, seul squeeze-lts évolue encore.

 Ok, merci pour la réponse.

 En même temps ma question était sans doute un peu bête, car le dépôt LTS
 perdrait tout son sens si le dépôt squeeze évoluait encore. ;)

Pourrait-on avoir le mode opératoire sous Debian,
sans faire ce que propose ce site :
www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/#GHOSTVulnerabilityCheck
à savoir # apt-get dist-upgrade
ce qui semble être un peu un canon pour tuer la mouche (même si elle est 
grosse).

N'y a t-il pas une méthode plus soft ?

Merci.

André

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/201501281419.01720.andre_deb...@numericable.fr

Re: Faille critique découverte dans GLIBC

Le 28/01/2015 14:34, Francois Lafont a écrit :

 Sous Squeeze ?
 Et bien comme indiqué ici par exemple : https://wiki.debian.org/fr/LTS/Using
 
 Perso, je ne me suis pas embêté :
 
 echo deb http://http.debian.net/debian/ squeeze-lts main contrib non-free  
 /etc/apt/sources.list.d/squeeze-lts.list
 apt-get update
 apt-get upgrade

Ah, au fait, petite question. Après les commandes ci-dessus,
faut-il que je fasse un reboot ?

Si j'ai bien compris, si un daemon dépend d'une lib, il faut
redémarrer le-dit daemon après la mise à jour de la-dite lib.
Seulement j'ai cru comprendre que globalement, quasiment tous
les daemons (sous Debian) dépendent in fine de la glibc et
qu'au final un reboot est globalement nécessaire. Bref, j'ai
lu je ne sais plus où que l'idée selon laquelle seule la
màj du noyau nécessitait un reboot était inexacte et que le
reboot était également nécessaire pour la màj de la glic.

Bref, ce serait possible d'avoir un avis d'expert sur la question ? ;)
Merci d'avance.

-- 
François Lafont

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/maap2l$ofv$1...@ger.gmane.org

Re: Faille critique découverte dans GLIBC

2015-01-28 Par sujet andre_debian

  Pourrait-on avoir le mode opératoire sous Debian,

 Sous Squeeze ?
 Et bien comme indiqué ici par exemple :
 https://wiki.debian.org/fr/LTS/Using

Je suis sous Wheezy...

 Perso, je ne me suis pas embêté :
 echo deb http://http.debian.net/debian/ squeeze-lts main contrib non-free
  /etc/apt/sources.list.d/squeeze-lts.list apt-get update
 apt-get upgrade
  sans faire ce que propose ce site :
  www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-c
 entos-rhel-linux/#GHOSTVulnerabilityCheck à savoir # apt-get
  dist-upgrade

 Perso, j'avoue que je l'utilise quotidiennement cette commande
 et je n'ai jamais eu de souci. Ai-je tort ?
 Si j'ai bien compris ce que dit la page man, avec upgrade aucune
 chance de voir un paquet supprimé etc. alors qu'avec dist-upgrade
 ça peut arriver.
 Évidemment si je mets des dépôts de la distribution n+1 dans les
 sources.list alors là un dist-upgrade peut faire des dégats mais
 sinon j'ai l'impression que dans 99% des cas un upgrade et un
 dist-upgrade font au final la même chose.
 De toute façon, si tu veux être prudent, tu fais un upgrade et
 puis voilà (en plus même avec un dist-upgrade, tu jettes un œil
 sur les modifications que souhaite faire la commande avant de
 confirmer).
 François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/201501281445.58433.andre_deb...@numericable.fr

Re: Faille critique découverte dans GLIBC


Bonjour à tous,

Pour l'instant, dans les dépôts squeeze-lts, le patch est dispo en amd64 
mais pas en i386.


Le 28/01/2015 08:52, Frédéric MASSOT a écrit :

Quelques autres liens :

- Les paquets corrigés :
https://security-tracker.debian.org/tracker/CVE-2015-0235

- http://www.openwall.com/lists/oss-security/2015/01/27/9
- https://linuxfr.org/users/peetah/journaux/faille-de-securite-glibc
- http://www.frsag.org/pipermail/frsag/2015-January/005722.html



--
Bernard.
20 ans d'utilisation de Debian. Comme le temps passe...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54c8a759.8080...@taranig.net

Re: Faille critique découverte dans GLIBC

Bonjour,

Le 28/01/2015 10:09, Bernard Isambert a écrit :

 Pour l'instant, dans les dépôts squeeze-lts, le patch est dispo en amd64 mais 
 pas en i386.

Est-ce qu'il y a une chance que le correctif soit tout simplement disponible
sur les dépôts squeeze « normaux » ?

-- 
François Lafont

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/maafsl$mnj$1...@ger.gmane.org

Re: Faille critique découverte dans GLIBC



Est-ce qu'il y a une chance que le correctif soit tout simplement disponible
sur les dépôts squeeze « normaux » ?


Non, seul squeeze-lts évolue encore.

--
Bernard.
20 ans d'utilisation de Debian. Comme le temps passe...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54c8cc3d.4020...@taranig.net

Re: Faille critique découverte dans GLIBC




Bonjour à tous,

Pour l'instant, dans les dépôts squeeze-lts, le patch est dispo en amd64
mais pas en i386.



C'était juste une question de temps, maintenant il est arrivé.

--
Bernard.
20 ans d'utilisation de Debian. Comme le temps passe...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54c8cd14.6070...@taranig.net

Re: Faille critique découverte dans GLIBC

Le 28/01/2015 12:47, Bernard Isambert a écrit :

 Est-ce qu'il y a une chance que le correctif soit tout simplement disponible
 sur les dépôts squeeze « normaux » ?

 Non, seul squeeze-lts évolue encore.

Ok, merci pour la réponse.

En même temps ma question était sans doute un peu bête, car le dépôt LTS 
perdrait
tout son sens si le dépôt squeeze évoluait encore. ;)

-- 
François Lafont

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/maaldd$m52$1...@ger.gmane.org

Re: Faille critique découverte dans GLIBC

2015-01-28 Par sujet andre_debian

On Wednesday 28 January 2015 15:50:11 Frédéric MASSOT wrote:
  Pourrait-on avoir le mode opératoire sous Debian,
  sans faire ce que propose ce site :
  www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-c
 entos-rhel-linux/#GHOSTVulnerabilityCheck à savoir # apt-get
  dist-upgrade
  ce qui semble être un peu un canon pour tuer la mouche (même si elle
  est grosse).
  N'y a t-il pas une méthode plus soft ?

 Oui bien sûr, tu mets à jour que la libc6.
 Quel paquet mettre à jour ?
 dpkg -l | grep libc6
 Puis : apt-get install la liste des paquets
 Les processus serveurs vont continuer d'utiliser l'image de l'ancienne
 libc6 qui est en mémoire, jusqu'à ce qu'ils soient redémarrés.

Merci beaucoup, mais cette méthode pourtant logique n'a pas marché.

Malgré un reboot, le test ghosttest me répondait toujours : Vulnerable.

J'ai fait un #apt-get upgrade
et au reboot : ghosttest = Non vulnerable.

André

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/201501281616.27938.andre_deb...@numericable.fr

Re: Faille critique découverte dans GLIBC

2015-01-28 Par sujet Frédéric MASSOT


Le 28/01/2015 14:19, andre_deb...@numericable.fr a écrit :

On Wednesday 28 January 2015 13:41:22 Francois Lafont wrote:

Le 28/01/2015 12:47, Bernard Isambert a écrit :

Est-ce qu'il y a une chance que le correctif soit tout simplement
disponible sur les dépôts squeeze « normaux » ?



Non, seul squeeze-lts évolue encore.



Ok, merci pour la réponse.

En même temps ma question était sans doute un peu bête, car le dépôt LTS
perdrait tout son sens si le dépôt squeeze évoluait encore. ;)


Pourrait-on avoir le mode opératoire sous Debian,
sans faire ce que propose ce site :
www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/#GHOSTVulnerabilityCheck
à savoir # apt-get dist-upgrade
ce qui semble être un peu un canon pour tuer la mouche (même si elle est 
grosse).

N'y a t-il pas une méthode plus soft ?


Oui bien sûr, tu mets à jour que la libc6.

Quel paquet mettre à jour ?

dpkg -l | grep libc6

Puis : apt-get install la liste des paquets

Les processus serveurs vont continuer d'utiliser l'image de l'ancienne 
libc6 qui est en mémoire, jusqu'à ce qu'ils soient redémarrés.


Sur les anciennes distrib, tu peux utiliser la commande checkrestart 
du paquet debian-goodies pour avoir la liste des daemons à redémarrer.


Sur les distrib plus récentes (wheezy-backports, jessie, sid)  tu peux 
utiliser la commande needrestart, du paquet du même nom, qui liste les 
daemons à redémarrer et les redémarre si tu le souhaite.


Une fois le paquet needrestart installé, il est lancé à la fin des 
installations par apt.



--
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54c8f723.6090...@juliana-multimedia.com

Re: Faille critique découverte dans GLIBC


Le 28/01/2015 20:59, Philippe Deleval a écrit :

Bonjour à tous

C'est une blague? A mon avis, tout programmeur utilisant la fonction de
bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où
il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s,
ct, n), le petit n fait la différence.

Cordialement


Philippe Deleval

Et ceux qui créé la fonction strcpy sont des criminels qui devraient 
être guillotinés sur le champ. Heureusement, Zorro est arrivé et a sauvé 
l'informatique...


--
Bernard.
20 ans d'utilisation de Debian. Comme le temps passe...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54c95fd0.4040...@taranig.net

Re: Faille critique découverte dans GLIBC

2015-01-28 Par sujet mrr


On 28/01/2015 15:00, Sébastien NOBILI wrote:

Bonjour,

Le mercredi 28 janvier 2015 à 14:43, Francois Lafont a écrit :

Le 28/01/2015 14:34, Francois Lafont a écrit :

echo deb http://http.debian.net/debian/ squeeze-lts main contrib non-free  
/etc/apt/sources.list.d/squeeze-lts.list
apt-get update
apt-get upgrade


Ah, au fait, petite question. Après les commandes ci-dessus,
faut-il que je fasse un reboot ?

Si j'ai bien compris, si un daemon dépend d'une lib, il faut
redémarrer le-dit daemon après la mise à jour de la-dite lib.
Seulement j'ai cru comprendre que globalement, quasiment tous
les daemons (sous Debian) dépendent in fine de la glibc et
qu'au final un reboot est globalement nécessaire. Bref, j'ai
lu je ne sais plus où que l'idée selon laquelle seule la
màj du noyau nécessitait un reboot était inexacte et que le
reboot était également nécessaire pour la màj de la glic.

Bref, ce serait possible d'avoir un avis d'expert sur la question ? ;)
Merci d'avance.


Loin de moi l'idée de me considérer comme tel…



moi non plus mais je voudrais nuancer ta réponse (car en pratique c'est 
clair qu'un reboot est juste simple et efficace mais: )


- La mise à jour de la glibc se contente peut-être de patcher quelques 
fichiers (diff), dans ce cas ce sont les programmes/daemons qui les 
utilisent qui auront besoin de la nouvelle version bien sûr. Peut-être 
aussi (pour ceux qui ne peuvent pas rebooter leur machine et il y en a, 
un simple logout/login) peut peut-être légèrement aider


- La libc fourni une librairie (minimale) pour les programmes écrits en 
C, donc ton démon écrit dans un autre langage ne devrait pas être touché 
cependant:


- Linux est écrit en C (bravo les gars au passage!), tous les appels 
systèmes ont été implémenté en C et en assembleur (qd c'était obligé, 
les registres par exemple ne sont pas directement accessibles en C, ou 
pour des raisons de performance) et:


	Certains appels systèmes en sont des vrais (par exemple fork je crois) 
mais d'autres ont des wrappers (désolé, je trouve pas la traduction là) 
autour ex:


	Des appels systèmes wait, waitpid, wait3, wait4 qui font tous à peu 
près la même chose (attendre (ou non) la fin d'un fils (présicément 
celui-là ou non)...) seul wait3 est réellement un appel système, les 
autres se contentant de l'appeler avec les bonnes options. Et je crois 
que ces wrappers (et d'autres trucs) dépendent de la libc. A moins 
qu'ils fassent également parti du noyau en fait.


Bon là je me perd et je dois partir bosser, toute correction à mes 
propos appréciée, je ne prétend pas à la vérité, c'est juste un point de 
vue.


Ceci étant dit, bonne journée les gars!


Il y a justement une discussion à ce sujet en ce moment sur debian-security [1].
Tous les programmes qui utilisent de la bibliothèque mise à jour doivent être
redémarrés. On doit donc redémarrer les services qui l'utilisent.

Dans le cas de la libc, ça devient problématique car _tous_ les programmes du
système l'utilisent. Il faut donc redémarrer _tous_ les programmes actuellement
en fonctionnement.

Deux approches :
 - tu les identifies un par un et tu les redémarres un par un (et tu ne fais
   rien d'autre de ta journée);
 - tu rebootes et c'est réglé en quelques minutes.

 1: https://lists.debian.org/debian-security/2015/01/msg00035.html

Seb




--
--
mrr

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54c9d852$0$3081$426a7...@news.free.fr

Re: Faille critique découverte dans GLIBC