Bonne grosse faille dans les procs pour commencer 2018...

[lol]

Salut,

http://www.lepoint.fr/economie/une-fail ... 891_28.php


Vous savez si des patchs sont déjà disponibles ?
Je suppose qu'il faut recompiler en attendant les noyaux déjà patchés ?

J'ai cru lire que ça pouvait ralentir les machines... Intox ?

[Mimoza]

Un peu plus d'info ici :
https://www.nextinpact.com/news/105903- ... -intel.htm
http://linuxfr.org/users/pied/journaux/ ... chez-intel

En gros 3 variantes d'une même faille. Les industriels touché ont été prévenu depuis Juin et un embargo cour normalement jusqu'au 9 Janvier (ce qui est énorme comme embargo !!!!) mais google a détaillé les failles avant l'heure (https://googleprojectzero.blogspot.fr/2 ... -side.html).
Le problème étant matériel tous les OS sur les archi touché sont plus ou moins concerné.
La faille est exploitable depuis du Javascript, donc extrêmement dangereuse pour tous !
Je ne suis pas encore sûr si le correctif va avoir des impacts sur les perf, les premier test parlait de 30% de perf en moins mais semblais limité aux appel système. Mais les derniers communiqué parle d'impact négligeable … bref encore un peu trop de FUD pour savoir ce qu'il en est vraiment.
Les patchs sont en cours de préparation et devrait être dispo très bientôt, les distrib vont faire leur boulot si tu es sur le noyau standard, sinon oui recompilation obligatoire.

Donc oui c'est de la bonne grosse faille pas facile a corriger car implique le matériel.

[lol]

Merci pour les liens et précisions.
Effectivement du sérieux. Attendons encore un peu.
Si j'ai bien compris c'est sur les machines virtuelles que c'est le plus emmerdant (possibilité d'outrepasser le cloisonnement) ?
Je n'ai pas réussi à comprendre/savoir s'il faut un accès physique ou au système pour les attaquants.

[piratebab]

phoronix a fait quelques essais comparatifs:
https://www.phoronix.com/scan.php?page= ... 6pti&num=2

[Mimoza]

Bon finalement c'est pas 1 mais 2 failles …
Un site explicatif : https://meltdownattack.com/

Ce n'est pas uniquement pour les VM, mais pour tout le système. En gros tu peux aller lire n'importe quelle zone mémoire même si celle çi est protégé. Donc embêtant pour tout ce qui est kernel/cookie/mot de passe/ …
Les VM/conteneur ont normalement pour avantage de cloisoner/isoler les processus, mais toutes leur sécurité est mise à mal avec cette faille.
Et pas besoin d'accès physique à la machine, juste un code JavaScript dans une page/pub est suffisant pour l'exploiter.

[hybridemoineau]

Le correctif pour Debian stable est sorti:
https://lists.debian.org/debian-securit ... 00000.html

Pour la confidentialité en javascript, ça va être coton. N'avoir qu'une page d'ouverte avant de se connecter à sa banque et/ou de payer en ligne puis vider le cache mémoire?

N'y a t-il pas une commande permettant de vider le cache mémoire ?

J'avais noté ça dans des temps antédiluviens. Ca donne quoi "en réalité" ?

Code : Tout sélectionner

# sync
# echo 1 > /proc/sys/vm/drop_caches
# echo 2 > /proc/sys/vm/drop_caches
# echo 3 > /proc/sys/vm/drop_caches 

Bon courage à tous ceux qui administrent des groupes de VM....

[Mimoza]

En discutant ce midi je comprend un peu mieux le principe.
Donc on a 1 seul «bug» qui est attaquable par 2 moyen distinct (plus variante).
Le truc est que lors d'une prédiction de branche le CPU va mettre dans un cache une partie de la mémoire et ne la vide pas immédiatement si la prédiction se révèle mauvaise, du coup un autre process peu aller lire ce qui s'y cache (oulà le super jeu de mot :icon_mrgreen:).
Donc ce n'est pas en vidant son cache OS/system que ça va régler le problème vu que c'est au niveau proc que ça se joue, mais je ne sais pas les commandes de @hybridemoineau sont pertinante car il y a toute une tripoté de cache (L1,L2,L3, …) dans un CPU.

[Mimoza]

Le package «intel-microcode» (non-free) est aussi a mettre à jour :
https://bugs.debian.org/cgi-bin/pkgrepo ... t=unstable

[lol]

Bon, c'est cool.
Comme d'habitude faire les mises à jour devrait suffire à protéger nos machines. Et la faille à l'air compliqué à exploiter en plus.
Je pense que comme d'habitude ce sont les "objets connectés" qui vont traîner la faille le plus longtemps...

[hybridemoineau]

Deux commandex pour savoir si le noyau qu'on emploie est patché contre meltdown:

Code : Tout sélectionner

$ dmesg | grep 'page tables isolation'

qui doit renvoyer si c'est bon :

Code : Tout sélectionner

[    0.000000] Kernel/User page tables isolation: enabled

Et rien sinon (à noter que je dois la lancer en root pour qu'elle marche, à moins que le noyau ne soit pas patché, auquel cas elle ne bronche pas)

Code : Tout sélectionner

grep cpu_insecure /proc/cpuinfo && echo "patched :)" || echo "unpatched :("
unpatched :(

qui doit renvoyer si c'est bon quelque chose comme

Code : Tout sélectionner

ugs            : cpu_insecure
bugs            : cpu_insecure
bugs            : cpu_insecure
bugs            : cpu_insecure
patched :)

et sinon

Code : Tout sélectionner

unpatched :(

C'est là où l'on paye le prix des noyaux exotiques: avec le 4.12 de la GalliumOS basé sur Ubuntu dont j'ai besoin, pas de patch, et pas de patch de prévu, je suis dépendant de l'équipe de la GalliumOS. Avec la dernière version du 4.9 de DEbian, c'est bon, mais sans le son... R l Cl !

Quant à ceux qui tournent sur des Chromebook comme sortis de l'oeuf, ils peuvent aller se rhabiller: rien de prévu sauf l'activation d'une vague option d'isolation dans le navigateur.

Open BSD n'a pas été prévenu, FreeBSD au dernier moment. Tout est bon pour sauver et gagner des parts de marché.

[piratebab]

pas encore patché sur la testing que je viens de mettre à jour

[sv0t]

Rien vu sur Android non plus

Je sais je sais mais je n'ai que ca en ce moment

Ok. Ok ==> []

[--gilles--]

pas encore patché sur la testing que je viens de mettre à jour

Normal : https://security-tracker.debian.org/tra ... -2017-5754


https://security-tracker.debian.org/tra ... -2017-5753

[piratebab]

intel-microcode viens de ce mettre à jour sur ma testing, mais pas encore de kernel patché

[PengouinPdt]

Beh, ce n'est pas le cas sous Sid, version 15.12.17 !

[wetaskiwin]

Beh, ce n'est pas le cas sous Sid, version 15.12.17 !

J'ai aussi la version 3.20171215.1 (sous sid) mais la mise à jour n'est arrivée que le 5 janvier 2018.

Aptitude 0.8.10: log report
Fri, Jan 5 2018 12:02:48 +0100

IMPORTANT: this log only lists intended actions; actions which fail
due to dpkg problems may not be completed.

Will install 33 packages, and remove 76 packages.
65.0 MB of disk space will be freed
…
[UPGRADE] intel-microcode:amd64 3.20171117.1 -> 3.20171215.1
…

C'est fait également pour le noyau 4.14.0-3.

[lol]

Hello,
Y'a un truc qui m'échappe... J'ai installé le noyau Stretch "patché" sur une Jessie mais ça ne semble pas bon.
Il me manque un truc ?

Code : Tout sélectionner

# uname -a
Linux xxx.xxx.xx 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux
root@xxx:~# dmesg | grep 'page tables isolation'
[    0.000000] Kernel/User page tables isolation: disabled

[hybridemoineau]

L'info vient de debian-facile, tirée elle-même de framasphère, et d'après le fil du forum, ça tousse un peu je ne comprends pas plus que ça...

https://debian-facile.org/viewtopic.php ... 68#p248868

[PengouinPdt]

juste quand même la page de suivi des bugs Debian : https://security-tracker.debian.org/tra ... kage/linux

Et suivre les infos des CVE correspondantes - à ce jour :

- https://security-tracker.debian.org/tra ... -2017-5754, correspond à Meltdown et est corrigée pour Stretch et Sid
- https://security-tracker.debian.org/tra ... -2017-5715 et https://security-tracker.debian.org/tra ... -2017-5753, correspondent à Spectre et sont non corrigées !

[lol]

Hello,
Le truc est pas clair en tout cas...

Code : Tout sélectionner

# uname -v
#1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04)
# lscpu | grep "Vendor ID\|Identifiant"
Identifiant constructeur : GenuineIntel
# dmesg | grep 'page tables isolation'
#

Code : Tout sélectionner

# uname -v
#1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04)
# lscpu | grep "Vendor ID\|Identifiant"
Identifiant constructeur : GenuineIntel
# dmesg | grep 'page tables isolation'
[    0.000000] Kernel/User page tables isolation: enabled
#

Code : Tout sélectionner

# uname -v
#1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04)
# lscpu | grep "Vendor ID\|Identifiant"
Vendor ID:             AuthenticAMD
# dmesg | grep 'page tables isolation'
[    0.000000] Kernel/User page tables isolation: disabled
#

Code : Tout sélectionner

apt-get changelog linux-image-4.9.0-5-amd64

* [amd64] Implement Kernel Page Table Isolation (KPTI, aka KAISER)
(CVE-2017-5754)

je ne vois rien sur Spectre (CVE-2017-5753 / CVE-2017-5715).
Bon... "Keep your systems up to date guys"...