Ubuntu Ultimate Edition

Le 20-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Kevin Denis ?crivait dans fr.comp.os.linux.debats :

Pourtant:
Un adminsitrateur système colle un mécanisme de style fail2ban
(ou autre) qui contrôle tous les processus en écoute avec
authentification. Donc dans la pratique, cette faille n'impactait que les
machines qui voulaient bien être touchées.

Ton point de vue c'est de dire qu'avec fail2ban, on contourne le
problème, c'est bien ça?

Non, seulement que pour n'importe quel OS, tu utilises ceinture _et_
bretelles.

Mais il est très confortable de penser que seul ssh est impacté.
Ainsi "il suffisait d'un fail2ban" après tout. Raisonnement un
poil court (dans tous les sens du terme; et sur le fait que
fail2ban suffit, et sur le fait que c'est la seule action à mener).

Euh... Chez moi, fail2ban bannit tout ce qui permet un accès
extérieur à une machine. Je te laisse conclure.

J'en conclus que tu n'as jamais entendu parler des slow ssh keyscan.

Si.

J'en conclus que tu imagines que fail2ban est la seule action à mener.

Non, mais tu peux configurer le truc pour être assez tranquille.

J'en conclus que tu raisonnes un poil court.

Merci. En terme de sécurité, je sais exactement ce que je fais. Je
sais aussi quels sont les risques que je prends.

,----------------------------------------------------------------.
| > Il faut que les clefs aient été créées avec _cette_ version |
| > spécifique de la bibliothèque. |
`----------------------------------------------------------------'

Je laisse le cadre.

Libre à toi.

Je n'ai qu'une seule machine qui était compromise (et c'est le
certificat https qui avait été recréé par mes soins avec effectivement
un openssl debian, et seulement celui-ci).

Donc tu estimes être safe car tu as mis fail2ban et que tu as régénéré
un certificat https.

Ce n'est _pas_ ce que j'ai écrit. J'ai écrit, relis-moi bien, que
les seules machines impactées ont été celles sur lesquelles il a fallu
générer un certificat durant la période où sévissait la bibliothèque
foireuse et que tu ne passes pas ta vie à générer des certificats pour
le plaisir. Et je t'ai dit que le seul certificat qui m'avait possé
problème était un certificat d'un site https (lequel site au passage
était piloté par un fail2ban bien senti).

C'est bien de vivre avec des oeillères. C'est ce
qui te fait dire que /usr/lib/man.conf n'existe pas car sur tes machines
il n'existe pas.
Là, désolé, mais ça me gonfle trop -> /dev/null

Parfait, tu commences sérieusement à m'énerver avec ta façon de lire
de travers. Je t'ai dit que sur d'autres OS que debian qui utilisaient
le man en question (et non man-db parce que ta comprenette est bouchée à
l'émeri), il n'y a strictement aucune configuration dans /usr/lib.
Si tu as une configuration dans /usr/lib, c'est soit parce que
l'intégrateur de ta distribution a jugé qu'il fallait le mettre là pour
une quelconque raison, soit que le développeur du soft a fumé. En, tout
état de cause, rien n'empêche de le coller _ailleurs_.

Donc dans la pratique, cette faille n'impactait que les
machines qui voulaient bien être touchées.

C'est faux, mais comme tu es persuadé que seul ssh était impacté, c'est
seulement vrai pour toi.

Je n'ai _jamais_ écrit ça. J'ai juste donné un exemple,

Qui se trouve être incomplet. Même chose, /dev/null.

Un exemple est par définition un cas particulier.

De plus en plus petit.

Allons, ne fait pas ta vierge effarouchée.

JKB <EOT>

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le Fri, 20 Mar 2009 21:21:29 +0100, *.-pipolin-.* a écrit :

sa logitech en produit 3D qui n'est pas au niveau de celle de windows.

j'ai aussi une souris logitech troidé et elle fonctionne bien sous linux.

Hugolino a écrit :

Le 19-03-2009, Jerome Lambert <jerome.lambert@swing.be> a écrit :

Hugolino a écrit :

Il y a un intérêt évident à passer sous Linux quand on veut des postes
verrouillés et simples à administrer, parce que Linux est prévu dès le
départ pour fonctionner en réseau. D'un simple serveur NFS à un projet
comme LTSP où les postes ne sont que des consoles graphiques, le choix
est très vaste, alors qu'un réseau sous Windows®, c'est la porte ouverte
au grand n'importe quoi et aux emmerdes sans fin.

Ce qui est bien avec toi, c'est que tu dis tout et son contraire, il
suffit de te laisser parler: d'un côté, tu reproches à Windows que "je
doute que les utilisateurs cherchent à en avoir une utilisation plus
poussée", alors que d'un autre côté, "Il y a un intérêt évident à passer
sous Linux quand on veut des postes verrouillés". Pas mal du tout.

Il n'y a aucune contradiction entre dire que windows est une sombre
merde qui ne peut fonctionner que s'il a été verrouillé par un admin
compétent et dire que *si* on veut verrouiller un poste bureautique,
alors c'est plus facile à faire avec un Linux.

En l'occurrence, ce n'est pas ce que tu as écris: tu reproches à Windows
de limiter les utilisateurs, et tu propose une solution qui est la
meilleure pour limiter les utilisateurs. Si tu ne vois pas la
contradiction...

La question n'est pas de vouloir, mais de *pouvoir* !
Or Windows® est un système obsur et non documenté, sans parler du fait
qu'il faut tout réapprendre à chaque nouvelle version.

Se former à connaître les entrailles de Windows, ça s'apprend. Si tu ne
veux pas faire l'effort intellectuel et financier, tu assumes. Il n'y a
pas de honte à ça: j'ai fait exactement le même choix en son temps, et
les sysadmins qui règlent des problèmes bien chi.nt en deux coups de
regedit ont toute mon admiration.

Je te le répète: « La question n'est pas de vouloir, mais de *pouvoir* ! »

Mais tu *peux*! Il suffit de savoir ce qu'il faut faire, donc de se
former, exactement comme sous n'importe quel OS (ou en n'importe quel
domaine, d'ailleurs).

Il m'est impossible de faire confiance à un OS, conçu par des esprits
malades, qui présente des boîtes de dialogue proposant d'« activer la
désactivation ».

Tu parles bien de cet OS dont certains services se désactivent par la ligne

disable = yes

placée dans les bons fichiers de configuration?

Cumbalero a écrit :

Jerome Lambert a écrit :

Je ne dis pas le contraire, mais croire que des utilisateurs
négligeants vont devenir exemplaires par un simple changement d'OS,
c'est au mieux risible.

Le simple fait qu'ils ne seront plus administrateur du système

Et pourquoi devraient-ils l'être? Ils ne peuvent pas changer
d'imprimante, installer de programmes, ou toute autre action qu'ils
faisaient précédemment? Sur leur propre machine, qui plus est?
Parce que si la solution proposée, c'est transformer des utilisateurs
qui ne savent pas gérer leur autonomie en utilisateurs complètement
assistés, c'est nous ramener 30 ans en arrière avec une informatique
réservée aux élites. Les former et leur apprendre à gérer convenablement
un OS est amha bien plus payant pour tout le monde.

Professeur Méphisto vient de nous annoncer :

Le Fri, 20 Mar 2009 21:21:29 +0100, *.-pipolin-.* a écrit :

sa logitech en produit 3D qui n'est pas au niveau de celle de windows.

j'ai aussi une souris logitech troidé et elle fonctionne bien sous linux.

juste bon à ramassé les coquilles...

ste misère...

--
Toutes les fautes d'orthographes de ce message sont sous copyright et
sont la propriété exclusive de l'auteur de ce message, toutes
reproductions est interdite et donnerais lieu à des poursuites.
© pipolin

Le 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :

Doug713705 a écrit :

Le Thu, 19 Mar 2009 21:08:57 +0100, pehache-tolai a écrit dans
news:72fn2jFpu9i6U1@mid.individual.net des mots en forme de phrase pour
nous dire :

Que le nom que l'on cherche soit celui d'une entrée dans la BDR ou un
nom de fichier, je ne vois pas ce que ça change.

- Le nombre de clefs dans la BDR est autrement plus important que le nombre
de fichiers de conf d'un système Linux comparable.

Sauf qu'une clé de BDR correspond plutôt à une ligne de fichier de conf,
donc pour comparer il faudrait faire un wc -l récursif sur /etc/ et
additionner tous les résultats en soustrayant les lignes vides.
Pas sûr du tout que la BDR Windows soit perdante d'avance...

Prends un outil au hasard comme Visiodent II et regarde _toutes_ les
entrées rajoutées par ce logiciel dans _toutes_ les branches de la base
de registre, qu'on se marre. Les principales clerfs sont dans
visiodent-40c, mais il en rajoute d'autres un peu partout. Pourquoi
est-ce que tout n'est pas sous visiodent ? Et je ne parle pas des clefs
qui devraient être associées à la local_user et qui se retrouvent dans
local_machine et les autres aberrations du même genre. La base de
registre est un truc hérité d'OS/2, sauf que sous OS/2, elle était
claire (en gros, c'était un fichier .ini compilé pour que son
accessibilité soit plus rapide sur les sysèmes de l'époque), utilisable
et surtout parfaitement bien documentée.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Christian <reply.valide@fr.invalld> wrote:

Jerome Lambert a écrit :

> Sauf qu'une clé de BDR correspond plutôt à une ligne de fichier de
> conf, donc pour comparer il faudrait faire un wc -l récursif sur etc
> et additionner tous les résultats en soustrayant les lignes vides.
> Pas sûr du tout que la BDR Windows soit perdante d'avance...

au niveau des lignes de commentaires, pas la peine d'un wc, la BDR a
perdu d'avance.

La base de registres a quoi de relationnel?


--

Michel TALON

Le 20-03-2009, JKB <knatschke@koenigsberg.fr> a écrit :

Ainsi "il suffisait d'un fail2ban" après tout. Raisonnement un
poil court (dans tous les sens du terme; et sur le fait que
fail2ban suffit, et sur le fait que c'est la seule action à mener).

Euh... Chez moi, fail2ban bannit tout ce qui permet un accès
extérieur à une machine. Je te laisse conclure.

J'en conclus que tu n'as jamais entendu parler des slow ssh keyscan.

Si.

Ok.

J'en conclus que tu imagines que fail2ban est la seule action à mener.

Non, mais tu peux configurer le truc pour être assez tranquille.

Puisque tu sais comment fonctionne les slow ssh keyscan, explique moi
comment tu configures fail2ban pour éviter le problème.

La doc de fail2ban indique:
"Fail2ban scans log files like /var/log/pwdfail or
/var/log/apache/error_log and bans IP that makes too many
password failures. It updates firewall rules to reject
the IP address. "

Et effectivement, fail2ban fonctionne très bien contre un attaquant
qui va bruteforcer depuis chez lui toutes les clés faibles debian.
Le principe repose sur le fait que l'attaquant utilise la _même_ IP
pour demander un très grand nombre de fois un mot de passe (ou une
clé).

Le slow ssh keyscan, c'est un botnet constitué de beaucoup de machines,
dont _chacune_ demande _un_ mot de passe à ta machine. Je ne vois pas en
quoi fail2ban peut aider, mais si tu as une configuration qui permet
d'être tranquille, je la prends.

Ce n'est _pas_ ce que j'ai écrit. J'ai écrit, relis-moi bien, que
les seules machines impactées ont été celles sur lesquelles il a fallu
générer un certificat durant la période où sévissait la bibliothèque
foireuse et que tu ne passes pas ta vie à générer des certificats pour
le plaisir.

Je te relis. Posément.
Les seules machines impactées (donc toutes les autres
ne le sont pas?) ont été celles sur lesquelles il a fallu générer un
certificat (un x509, ou bien tu dis un certificat de manière générale
pour signifier n'importe quelle clé? Ce n'est pas la même chose)
durant la période où sévissait la bibliothèque foireuse. Tu ajoutes
que tu ne passes pas ta vie à générer des certificats.

Ok. Posons les choses. La faille a durée deux ans. Les x509 que je
génère ont justement une durée de vie de deux ans. Et au bout des deux
ans, je les remplace avec un nouveau bi-clé et je recertifie.
Ton argument serait valable si la faille avait duré deux semaines,
mais là, deux ans! La fenêtre est beaucoup trop large pour pouvoir
ne serait-ce qu'esperer minimiser la chose.

Ensuite, on parle de certificats, parlons d'autorité. Et là, si tu
as mis en oeuvre une PKI avec une CA basée sur une clé faible, c'est
le drame. Il vaut mieux casser l'intégralité de ta PKI et en reprendre
une autre à côté. Casser une CA, ça fait une énormité de dégats
collatéraux, et ça demande du temps à être refait.

Enfin, tu ne parles que des certificats.
N'as tu jamais créé de comptes utilisateurs en deux ans? Ces utilisateurs
ont sans doute créés des clés via ssh. Ils ont copié leur clés chez leurs
voisins afin de se logger avec ssh plus facilement. Note que le voisin peut
être sous NetBSD, gentoo ou solaris. Une fois que la faille est découverte
il suffit d'aller scanner ces machines en espérant tomber sur une clé
faible debian.
Cette faille n'a pas touché que debian, elle a aussi arrosé la moitié
de la planète. Et bien que je n'aie pas de debian, j'ai du aller
vérifier toutes mes machines. De plus, j'ai du vérifier tous mes
certificats au cas (certes peu probable mais le cas existe) ou un des
miens fasse partie des clés faibles debian.
Et encore aujourd'hui, à chaque génération de clés, je dois vérifier
qu'elle n'est pas faible.
Imagine que windows fasse une bêtise qui impacte directement la sécurité
de tes Solaris, et qu'il faille les patcher très rapidement, tu réagirais
comment? Surtout que par la suite, tu sois obligé de toujours regarder
à deux fois ce que tu fais car la faille est là.

Pour finir, il y a eu des tas de gens qui ont utilisés des debian
impactées par cette faille. Et des tas d'autres gens qui ont capturé
du trafic réseau. Il y a peut être même eu des gens qui ont capturés
des échanges réseaux complets entre ton serveur web vulnérable et
le client. Le serveur web est protégé par fail2ban, certes. Mais
l'échange de données, lui, est facilement en clair pour l'attaquant.

Imaginons un site web https protégé par fail2ban dont l'accès se
fait via un login/pass. Je sniffe l'échange de trafic, je déchiffre,
je récupère l'identifiant. Je me connecte en https. Je me logge avec cet
identifiant, fail2ban monitore éventuellement ma connexion, je suis
loggé car j'ai un bon mot de passe. pwned.


Alors dire "cette faille ne touchait que ceux qui voulaent être touchés"
non, vraiment non.
Cette faille a touché beaucoup de monde, elle est dramatique, et sa portée
dépasse très largement une faille comme vmsplice qui te permet seulement
de passer root à la condition d'avoir déjà un compte shell sur la
machine.. (de plus j'ai vu un patch de vmsplice à chaud, sans reboot). Des
failles qui te donnent une élévation de privilèges, il y en a 3 par
semaines. Pas de quoi m'empêcher de dormir. La debacle debian, c'est
autrement plus compromettant.

Je te relis de nouveau.

les seules machines impactées ont été celles sur lesquelles il a fallu
générer un certificat durant la période où sévissait la bibliothèque
foireuse

Les "seules machines", non, La moitié d'internet. "Sur lesquelles il a fallu
générer un certificat". Non plus.

La page http://wiki.debian.org/SSLkeys recense 31 applications impactées.
Mais c'est vrai, je le reconnais, tu as raison, il suffisait de ne pas
utiliser ces applications pendant 2 ans.

Ceci dit nous parlions des fichiers de conf mal rangés sous linux.
--
Kevin

Le 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Kevin Denis ?crivait dans fr.comp.os.linux.debats :

Le 20-03-2009, JKB <knatschke@koenigsberg.fr> a écrit :

Ainsi "il suffisait d'un fail2ban" après tout. Raisonnement un
poil court (dans tous les sens du terme; et sur le fait que
fail2ban suffit, et sur le fait que c'est la seule action à mener).

Euh... Chez moi, fail2ban bannit tout ce qui permet un accès
extérieur à une machine. Je te laisse conclure.

J'en conclus que tu n'as jamais entendu parler des slow ssh keyscan.

Si.

Ok.

J'en conclus que tu imagines que fail2ban est la seule action à mener.

Non, mais tu peux configurer le truc pour être assez tranquille.

Puisque tu sais comment fonctionne les slow ssh keyscan, explique moi
comment tu configures fail2ban pour éviter le problème.

La doc de fail2ban indique:
"Fail2ban scans log files like /var/log/pwdfail or
/var/log/apache/error_log and bans IP that makes too many
password failures. It updates firewall rules to reject
the IP address. "

Et effectivement, fail2ban fonctionne très bien contre un attaquant
qui va bruteforcer depuis chez lui toutes les clés faibles debian.
Le principe repose sur le fait que l'attaquant utilise la _même_ IP
pour demander un très grand nombre de fois un mot de passe (ou une
clé).

Le slow ssh keyscan, c'est un botnet constitué de beaucoup de machines,
dont _chacune_ demande _un_ mot de passe à ta machine. Je ne vois pas en
quoi fail2ban peut aider, mais si tu as une configuration qui permet
d'être tranquille, je la prends.

Oui, j'ai une configuration qui me permet d'être tranquille parce
que j'utilise mes propres modules dans fail2ban. En particulier je
blackliste toutes les adresses en dehors d'un pool de whitelist dès que
j'ai trop d'erreurs dans les logs. Je te laisse l'écrire, ce n'est pas
bien compliqué.

Ce n'est _pas_ ce que j'ai écrit. J'ai écrit, relis-moi bien, que
les seules machines impactées ont été celles sur lesquelles il a fallu
générer un certificat durant la période où sévissait la bibliothèque
foireuse et que tu ne passes pas ta vie à générer des certificats pour
le plaisir.

Je te relis. Posément.
Les seules machines impactées (donc toutes les autres
ne le sont pas?) ont été celles sur lesquelles il a fallu générer un
certificat (un x509, ou bien tu dis un certificat de manière générale
pour signifier n'importe quelle clé? Ce n'est pas la même chose)
durant la période où sévissait la bibliothèque foireuse. Tu ajoutes
que tu ne passes pas ta vie à générer des certificats.

Ok. Posons les choses. La faille a durée deux ans. Les x509 que je
génère ont justement une durée de vie de deux ans. Et au bout des deux
ans, je les remplace avec un nouveau bi-clé et je recertifie.
Ton argument serait valable si la faille avait duré deux semaines,
mais là, deux ans! La fenêtre est beaucoup trop large pour pouvoir
ne serait-ce qu'esperer minimiser la chose.

Dommage. Mes certificats ont par défaut une durée de cinq ans et je
ne les résilie que si je n'ai pas le choix. Par ailleurs, leur longueur
est par défaut 4096.

Ensuite, on parle de certificats, parlons d'autorité. Et là, si tu
as mis en oeuvre une PKI avec une CA basée sur une clé faible, c'est
le drame. Il vaut mieux casser l'intégralité de ta PKI et en reprendre
une autre à côté. Casser une CA, ça fait une énormité de dégats
collatéraux, et ça demande du temps à être refait.

Nous sommes bien d'accord.

Enfin, tu ne parles que des certificats.
N'as tu jamais créé de comptes utilisateurs en deux ans? Ces utilisateurs
ont sans doute créés des clés via ssh.

Non. Je suis paranoïaque et les utilisateurs n'ont généralement
pas à se logguer directement sur mes machines. Leur shell est généralement
/bin/false pour un certain nombre de raisons. Pour les mêmes raisons, les
utilisateurs qui ont un shell normal ne peuvent pas se connecter de
l'extérieur (sauf exception, mais ils sont alors chrootés).

Ils ont copié leur clés chez leurs
voisins afin de se logger avec ssh plus facilement. Note que le voisin peut
être sous NetBSD, gentoo ou solaris. Une fois que la faille est découverte
il suffit d'aller scanner ces machines en espérant tomber sur une clé
faible debian.
Cette faille n'a pas touché que debian, elle a aussi arrosé la moitié
de la planète. Et bien que je n'aie pas de debian, j'ai du aller
vérifier toutes mes machines. De plus, j'ai du vérifier tous mes
certificats au cas (certes peu probable mais le cas existe) ou un des
miens fasse partie des clés faibles debian.
Et encore aujourd'hui, à chaque génération de clés, je dois vérifier
qu'elle n'est pas faible.
Imagine que windows fasse une bêtise qui impacte directement la sécurité
de tes Solaris, et qu'il faille les patcher très rapidement, tu réagirais
comment? Surtout que par la suite, tu sois obligé de toujours regarder
à deux fois ce que tu fais car la faille est là.

Je te répondrai exactement la même chose. Ceinture _et_ bretelles. Tu
ne peux toucher aucune de mes machines Solaris directement sans passer
par une autre au passage qui filtre, loggue et triture les accès (mais
que tu ne vois même pas.). Pour un certain nombre de raisons de sécurité,
je n'ai aucune machine Solaris directement sur le réseau internet.

Pour finir, il y a eu des tas de gens qui ont utilisés des debian
impactées par cette faille. Et des tas d'autres gens qui ont capturé
du trafic réseau. Il y a peut être même eu des gens qui ont capturés
des échanges réseaux complets entre ton serveur web vulnérable et
le client. Le serveur web est protégé par fail2ban, certes. Mais
l'échange de données, lui, est facilement en clair pour l'attaquant.

Imaginons un site web https protégé par fail2ban dont l'accès se
fait via un login/pass. Je sniffe l'échange de trafic, je déchiffre,
je récupère l'identifiant. Je me connecte en https. Je me logge avec cet
identifiant, fail2ban monitore éventuellement ma connexion, je suis
loggé car j'ai un bon mot de passe. pwned.

Sniffe tant que tu veux. Je t'ai dit que j'étais paranoïaque et que
je ne faisais _jamais_ confiance à un seul système. Même avec le login
et le mot de passe, tu n'arriveras pas à entrer sur un de mes sites
sécurisés parce qu'il y a un second mécanisme (un truc qui utilise un mot
de passe créé à la volée).

Alors dire "cette faille ne touchait que ceux qui voulaent être touchés"
non, vraiment non.

Si. Pour être _réellement_ affecté par cette faille, il fallait que
toute ta sécurité repose sur la clef ou les clefs vulnérables. Je sais,
la plupart des gens font aveuglément confiance à ssl. J'ajouterais que ce
n'est pas mon problème. C'est un peu comme les gens qui font actuellement une
confiance absolue à sha1. Que se passera-t-il lorsqu'on trouvera une
manière de casser sha1 ? Ce n'est pas pour cela que je n'utilise pas
sha1, mais jamais seul !

Cette faille a touché beaucoup de monde, elle est dramatique, et sa portée
dépasse très largement une faille comme vmsplice qui te permet seulement
de passer root à la condition d'avoir déjà un compte shell sur la
machine..

C'est au contraire _très_ facile vu le nombre de machines
administrées par des pieds avec des shells par défaut pour des simples
serveurs de messagerie et autres ! J'ai des tas de connaissances qui ont
été percées grâce à vmsplice(). Et on retombe toujours sur la même
chose, à savoir les compétences (et la bonne compréhension) nécessaires
à l'administration d'un système un tant soit peu sécurisé (c'est
d'ailleurs pour cela qu'un vrai administrateur système, c'est cher).

(de plus j'ai vu un patch de vmsplice à chaud, sans reboot). Des
failles qui te donnent une élévation de privilèges, il y en a 3 par
semaines. Pas de quoi m'empêcher de dormir. La debacle debian, c'est
autrement plus compromettant.

Non, les deux sont emmerdantes et pour les mêmes raisons, à savoir
l'incompétence des administrateurs.

Je te relis de nouveau.

les seules machines impactées ont été celles sur lesquelles il a fallu
générer un certificat durant la période où sévissait la bibliothèque
foireuse

Les "seules machines", non, La moitié d'internet. "Sur lesquelles il a fallu
générer un certificat". Non plus.

La page http://wiki.debian.org/SSLkeys recense 31 applications impactées.
Mais c'est vrai, je le reconnais, tu as raison, il suffisait de ne pas
utiliser ces applications pendant 2 ans.

Ceci dit nous parlions des fichiers de conf mal rangés sous linux.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le Sat, 21 Mar 2009 09:48:45 +0100, *.-pipolin-.* a écrit :

ste misère

C'est votre sainte patronne ?