Journal Noyau vulnérable ou pas ?

34
22
jan.
2018

Avec toute l'agitation et la parution rapide des patchs au sujet des failles Meltdown et Spectre il peut être difficile de savoir si son processeur est affecté et quel est le niveau exact de protection de sa machine.
Afin d'aider les utilisateurs à trouver l'information, le développeur Thomas Gleixner a introduit un nouveau mécanisme qui permet d'avoir une vue unifiée de l'état actuel de son noyau.

Greg Kroah-Hartman a posté un petit article à ce sujet pour expliquer la commande à lancer :

grep . /sys/devices/system/cpu/vulnerabilities/*

Cela retourne le statut pour chaque vulnérabilité (Meltdown, Spectre V1 et Spectre V2) :

/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable: Minimal generic ASM retpoline

On voit que sur le noyau de Greg la faille Meltdown est comblé (par la fonction de Page Table Isolation). Que la faille Spectre V1 est encore grande ouverte tandis que la faille Spectre V2 n'est que partiellement corrigée par le mécanisme Retpoline.

Bien entendu cette commande ne fonctionne que sur les toutes dernières versions du noyau (4.14.14 et rétroportage sur les versions LTS).
Comme le dit Greg :

If your kernel does not have that sysfs directory or files, then obviously there is a problem and you need to upgrade your kernel!

Pour info, avec la dernière mise à jour du noyau effectuée aujourd'hui, voici le résultat de la commande sur mon laptop sous Arch Linux :

[patrick@laptop]: ~>$ grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline
[patrick@laptop]: ~>$

  • # Risque ?

    Posté par (page perso) . Évalué à 4.

    Merci pour cette information.

    Mais, franchement, que risques-tu, sur ton laptop, si ces failles ne sont pas corrigées (on va dire qu'il n'y a que toi qui l'utilise, et que tu n'a installé que des paquets open source) ?

    • [^] # Re: Risque ?

      Posté par . Évalué à 10.

      Tu risques autant qu'en grillant un feu rouge le soir sur une route déserte où tu vois clairement qu'il n'y a personne à la ronde.

      La sécurité (un peu comme la sûreté) c'est un entassement de couches. Quand un pb arrive c'est toujours une accumulation de la perte de plusieurs couches, à chaque fois pour un truc insignifiant.

      Ce pb aujourd'hui tel qui est énoncé n'est peut-être pas très significatif (hormis l'utilisation de virtualisation cloud peut-être), mais c'est encore une fois une couche qui s'effondre : en concevant ton OS tu pars du principe que le CPU t'assure certaines protections… qui n'existent plus. C'est une couche parmi tant d'autres.

      On ne sait pas encore comment ce sera exploité, mais là n'est pas le pb : le CPU doit faire son boulot de CPU.

      • [^] # Re: Risque ?

        Posté par (page perso) . Évalué à 1.

        Tu risques autant qu'en grillant un feu rouge le soir sur une route déserte où tu vois clairement qu'il n'y a personne à la ronde.

        … et que tu sais qu'il y a des snipers embusqués prêts à tirer sur tout ce qui bouge.

        Ce pb aujourd'hui tel qui est énoncé n'est peut-être pas très significatif (hormis l'utilisation de virtualisation cloud peut-être)

        Le problème est très significatif, puisque cela peut permettre à un processus d'accéder à tous les autres processus de l'hôte. C'est dramatique pour un hyperviseur, mais aussi pour un ordinateur de bureau : on clique sur un mauvais lien dans son navigateur et boum, un attaquant a accès à nos documents, nos mots de passe, nos photos.

        On ne sait pas encore comment ce sera exploité, mais là n'est pas le pb : le CPU doit faire son boulot de CPU.

        Les vidéos sur en milieu de page https://meltdownattack.com sont quand même assez explicites. Ce sera exploité rapidement, ça l'est sûrement déjà (car si la faille a été révélée maintenant, rien ne dit que certains ne la connaissaient pas avant).

    • [^] # Re: Risque ?

      Posté par . Évalué à 9.

      En théorie à partir du moment où tu browses et ne désactive pas tout javascript, il n'y a jamais que toi qui utilise ton pc.

      Le danger peut venir de n'importe quelle application communiquant en réseau et qui aurait elle-même une faille. Après effectivement si la faille est mitigée par le patching des applis communiquant avec l'extérieur, comme ton navigateur par exemple, le danger est déjà bien plus faible.

    • [^] # Re: Risque ?

      Posté par (page perso) . Évalué à 4.

      Il y a une implémentation de Spectre en Javascript, décrite dans le papier original. Il risque donc de voir sa mémoire lue par un script tiers juste en navigant sur le web.

    • [^] # Re: Risque ?

      Posté par (page perso) . Évalué à 4.

      Il est évident que plus tu fais attention à ta machine (système à jour, installation de moins de logiciels et provenant de sources sûres), plus le risque au sujet des failles de manière générale sera faible.

      Cependant ce n'est pas suffisant, typiquement ici ce sont des failles potentiellement exploitable en utilisant que des logiciels "sûrs" type Firefox. Car beaucoup de logiciels ont de quoi interpréter du code (dans le cas du navigateur, le JavaScript est particulièrement évident) et si le code injecté est malveillant, ce n'est pas bon. De même au sujet des machines virtuelles par rapport à la machine hôte.

      Concernant ces failles en particulier, si les conséquences peuvent être désastreuses, cela reste des failles assez complexes à exploiter convenablement. S'il est facile d'extraire des données du cache ou du noyau par exemple, encore faut-il réussir à obtenir (et comprendre) les données pertinentes pour l'attaquant. L'attaquant ne semble pas avoir un contrôle là dessus. Je n'ai pas l'impression qu'il soit possible d'extraire volontairement et simplement des données sensibles (données persos, mots de passe ou clé cryptographiques) sur demande.

      Après je peux me tromper, je serais intéressé d'ailleurs de savoir si je fais fausse route là dessus.

      • [^] # Re: Risque ?

        Posté par (page perso) . Évalué à 4.

        Disons que pour Meltdown, le débit de fuite c'est jusqu'à 500KB/s, c'est-à-dire beaucoup et c'est en partie là le problème qui rend la vulnérabilité vraiment pratique. Pour Spectre c'est moins, je me souviens plus exactement, quelque chose comme 10 fois moins je crois (ce qui n'est pas négligeable non plus).

        • [^] # Re: Risque ?

          Posté par (page perso) . Évalué à 3.

          Disons que pour Meltdown, le débit de fuite c'est jusqu'à 500KB/s, c'est-à-dire beaucoup et c'est en partie là le problème qui rend la vulnérabilité vraiment pratique.

          Je le sais bien. Mais bon, le contenu dans le cache est très mouvant (pour des caches de plusieurs Mio, ce qui devient de plus en plus courant, cela est difficile de tout récupérer avant un changement important de son contenu).

          Puis encore faut-il, avec un dump du cache, réussir à comprendre la signification de la donnée récoltée pour en tirer quelque chose. Loin d'être impossible, mais ce n'est pas non plus immédiat et cela réduit le risque (je pense) d'une attaque d'envergure.

        • [^] # Re: Risque ?

          Posté par . Évalué à 4.

          500KB/s

          Kilo Bits, ou Kilo Bytes, du coup? Je ne suis jamais sûr de comprendre quelle unité est la bonne quand c'est un b…

          • [^] # Re: Risque ?

            Posté par (page perso) . Évalué à 7.

            Kilo Bits, ou Kilo Bytes, du coup?

            Kilo-octets. Extrait du papier sur Meltdown :

            we can dump kernel and physical memory with up to 503 KB/s. Hence, an enormous number of systems are affected.

            Et sur Spectre les chiffres sont plus petits mais ils disent que le code n'est pas optimisé :

            The unoptimized code in Appendix A reads approximately 10KB/second on an i7 Surface Pro 3.

          • [^] # Re: Risque ?

            Posté par . Évalué à 4. Dernière modification le 22/01/18 à 19:17.

            Il me semble que B majuscule est pour byte (= 1 octet si la taille du bytes est de 8 bits, ce qui est quasiment vrai tout le temps) et le b minuscule pour bit.

            Le k pour kilo ne doit pas être en majuscule :

            1kb/s : un kilo-bit par seconde
            1kB/s : un kilo-octet (un kilo-byte) par seconde

            On devrait même écrire : 1kiB/s pour être conforme à la norme ISO mais c’est complètement débile… (vu que par 1 kilobyte on entend plutôt 1024 bytes, et pas 1000 bytes…)

            « Normalement »… 1kiB = 1024 bytes et 1kB = 1000 bytes. Mais je le redis, c’est stupide.

            • [^] # Re: Risque ?

              Posté par . Évalué à 0. Dernière modification le 22/01/18 à 20:55.

              Il me semble que B majuscule est pour byte (= 1 octet si la taille du bytes est de 8 bits, ce qui est quasiment vrai tout le temps) et le b minuscule pour bit.

              Je t'avoues que je trouverais plus simple de parler de bauds et d'o/s, mais c'est vrai que le baud est plutôt une mesure à très bas niveau.
              D'ailleurs, je ne comprendrai jamais pourquoi on parle de débit réseau (souvent internet/GPRS/whatever) en bits ou bytes par seconde, et non de bauds, mais c'est différent, puisque le baud est trop proche du matériel pour être pertinent dans le cas d'un accès à de la RAM j'imagine.

              On devrait même écrire […] mais c’est complètement débile

              Bah non, la norme ISO se base, je pense, sur des puissances de 10, pour être consistante sur le système métrique. C'est vrai que c'est un peu étrange au début, mais quand on y pense, si l'objectif est d'avoir un truc qui tiens la route pour toutes les disciplines tout autour du monde, le fait que tous les systèmes adoptent la même base pour les puissances est une excellente chose.
              C'est vrai, moi aussi je trouve ça un peu ridicule, de parler de puissances qui ne sont pas elle-même des puissances de 2 en informatique, parce que ça ne marche pas comme ça dans le bestiau (quoique, pour les disques durs, si on regarde la quantité réelle utilisable par l'interface normale, qui permets d'avoir des secteurs de secours notamment, c'est pas si sûr)… mais dans ce cas, on pourrait nous rétorquer que les kilomètres, ça ne fait 1000 mètres que parce qu'on en a décidé ainsi.

              Bref, perso j'aime bien la solution employée par l'ISO: elle nous permets de garder la spécificité technique (et relativement historique), tout en ayant une mesure qui nous permets d'être compris et uniforme avec d'autres domaines.
              Après, non, c'est sûr, c'est pas aussi précis, mais de mémoire, on me disais à l'école d'arrondir les résultats sur les copies (on s'amusait pas à écrire les 20 chiffres du nombre exact, on mettais, en gros, 3 chiffres pour former un nombre entier, avec 2 chiffres pour les flottants, et une puissance… de 10, elle-même multiple de 3. C'était de l'électronique.).

              • [^] # Re: Risque ?

                Posté par . Évalué à 3.

                avoir un truc qui tiens la route pour toutes les disciplines tout autour du monde

                En quoi l’ancien système ne tenait pas la route ?

                Chaque domaine peut avoir ses spécificités. L’espace mémoire d’un ordinateur n’est pas une des sept grandeurs physiques de base ni ne dérive de celles-ci. Pourquoi ne pourrait-on pas continuer à « surcharger » ces préfixes multiplicateurs pour cette grandeur là ?

                • [^] # Re: Risque ?

                  Posté par . Évalué à 5.

                  Hum… j'allais prendre un contre-exemple pour arguer du fait que le SI est consistant, mais en le prenant, j'ai fait l'«erreur» de me documenter pour me sourcer.

                  Il s'avère que, selon wikipedia toutes les unités ne sont pas basées sur une base 10. D'un autre côté, cet exemple (le parsec) pris au hasard peut être considéré comme une unité de base, l'équivalent du mètre, en somme.

                  À contrario, en informatique, ce sont les multiplicateurs que l'on altère, ce qui favorise l'incompréhension je pense.
                  Par exemple, SpeedCrunch m'indique que:

                  1Kio, soit 210 octets => 1024, erreur de 2.4% par rapport à la norme
                  1Mio, soit 220 octets => 1048576, erreur de 4.8% par rapport à la norme

                  Bref, plus on augmente les valeurs (plus ça va, plus ça monte, on passe à pas loin de 7.3% pour le Gio, et presque 10% pour le Gio; notes que je n'ai pas trouvé de référence pour savoir si on écrit la 1ère lettre du multiplicateur en majuscule ou non: il me semble que si mais…), plus le risque d'erreur induit par l'interprétation classique est élevé.
                  D'ailleurs, même si je connais la valeur exacte de 210, d'un Kio donc, je serais incapable de dire combien vaut 1Mio, alors qu'un mo, selon le système international, si. Du coup, pour dimensionner des systèmes, c'est mieux de parler de Mo que de Mio à mon avis.

                  Du coup, la question, c'est pourquoi utiliser des puissances de 2? Pour l'adressage? Pour indiquer aux gens la capacité des machines qu'ils utilisent? Pour comprendre ce que peux contenir un disque dur que l'on va acheter?
                  Perso, quand on me parle de Kio, je sais que je vais devoir me méfier et recourir à une calculatrice si je veux manipuler de grands nombres. Avec des Ko, à moins que l'auteur n'ait explicitement exprimé qu'il utilise notre système historique (ou que je puisse le demander), je reste soumis au doute, et, un jour de fatigue, je pourrais faire une approximation fausse de plus de 4%, ce qui n'est pas spécialement faible pour moi.

                  Je ne saurais dire si un système me persuade alors que l'autre me convainc mais je balance entre les deux :)

                  • [^] # Re: Risque ?

                    Posté par (page perso) . Évalué à 4.

                    Ça tombe bien, le parsec n'est pas une unité du SI, qui reste donc bien cohérent (et non consistant).

                    Du coup, la question, c'est pourquoi utiliser des puissances de 2 ?
                    Pour l'adressage ?

                    dans ce cas, on utilise de l'hexadécimal, et ce n'est pas pour indiquer réellement une taille (et donc on n'utilise pas les préfixes, vu qu'on veut l'adresse en entier)

                    Pour indiquer aux gens la capacité des machines qu'ils utilisent ?

                    je ne vois pas en quoi les puissances de 2 indiquent mieux la capacité des machines que les puissances de 10.

                    Pour comprendre ce que peux contenir un disque dur que l'on va acheter?

                    idem. Je peux immédiatement comparer un disque de 0,49 To et un disque de 500 Go. Peux-tu faire la même chose avec des disques de 0,49 Tio et de 500 Gio ?

                    • [^] # Re: Risque ?

                      Posté par . Évalué à 2.

                      Ça tombe bien, le parsec n'est pas une unité du SI, qui reste donc bien cohérent (et non consistant).

                      J'ai lu trop vite donc, et avec trop de CTRL+F.

                      dans ce cas, […]

                      e ne vois pas en quoi […]

                      idem […]

                      J'ai l'impression que la plupart de tes points retombent sur mon avis, pour le coup :D
                      J'avais justement posé ces questions pour faire répondre quelqu'un qui considère le SI comme non pertinent.

                      • [^] # Re: Risque ?

                        Posté par (page perso) . Évalué à 1.

                        Je pense que c'est juste historique. Quand on parlait seulement de kB et que les MB étaient réservés aux super-calculateurs, la différence d'estimation était petite. En plus, les chiffres étaient rond parce que les systèmes sont conçues en assemblant des modules par basés sur des puissances de 2.

                        Je pense que la transition se fait juste difficilement parce que les gens n'y réfléchissent pas trop et restent coincés dans leurs habitudes.

                        • [^] # Re: Risque ?

                          Posté par (page perso) . Évalué à 8.

                          En plus, les chiffres étaient rond parce que les systèmes sont conçues en assemblant des modules par basés sur des puissances de 2.

                          Tout à fait, c'est pourquoi globalement toute l'informatique emploient des unités en base deux : nos ordinateurs sont en général l'association de composants qui reposent eux même sur la base 2. Et pourquoi s'en est ainsi ?

                          Outre le fait que l'information est stockée sous forme de bits, n'oublions pas qu'en électronique il est très courant de juste recopier un motif de composants ou de fils pour les doubler, quadrupler, etc. On retrouve la base 2 dans ce procédé.

                          Cependant, il y a un endroit de stockage où la base 2 ne fonctionne pas : le stockage de masse magnétique. Les disquettes comme les disques durs, de par leur conception et géométrie n'ont pas ces propriétés des autres composants électroniques comme le processeur, la RAM ou la mémoire flash. C'est à cause de ces composants que le flou entre Ko et Kio ont commencé à émerger.

                          Le soucis est le manque de cohérence autour de ces unités. Par exemple globalement sous GNU/Linux, l'ensemble utilise les préfixe type Kio. Mais sous Windows, c'est les Ko qui sont affichés (alors qu'en interne cela utilise bien des Kio pour les calculs). Les fabricants des disques durs utilisent aussi les Ko probablement pour des raisons commerciales. Cela est trompeur, de nombreux utilisateurs ne comprennent pas pourquoi un disque dur de 1 To n'en fait en réalité que 900 Gio (suffit de voir la quantité de messages à ce sujet sur Internet).

                          Mais bon, le manque de cohérence ne se limite pas là. Techniquement on devrait utiliser en anglais aussi les octets au lieu des bytes. Le premier étant explicitement un regroupement de 8 bits alors que le second est le plus petit mot compréhensible pour la machine. Globalement les deux sont identiques depuis 20 ans, mais cela n'a pas toujours été le cas et techniquement, rien ne dit que cela durera éternellement. En plus d'être source d'erreur car à une majuscule près, un facteur 8 est compté ou pas (bits au lieu de bytes).

                    • [^] # Re: Risque ?

                      Posté par . Évalué à 2.

                      C'est plus facile en hexa: 0x0,7F Tio est évidement plus petit que 0x200 Gio :-)

                    • [^] # Re: Risque ?

                      Posté par . Évalué à 1.

                      C'est plus facile en hexa: 0x0,7F Tio est évidement plus petit que 0x200 Gio :-)

              • [^] # Re: Risque ?

                Posté par (page perso) . Évalué à 4.

                D'ailleurs, je ne comprendrai jamais pourquoi on parle de débit réseau (souvent internet/GPRS/whatever) en bits ou bytes par seconde, et non de bauds

                Parce que le baud ne donne aucune information pratique pour l'utilisateur du réseau. Tu peux avoir un réseau avec 10 bauds par secondes et un débit de 12 bits par secondes (ou l'inverse). À moins de connaître précisément la technologie utilisée, le baud n'est pas une information pertinente.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: Risque ?

                  Posté par . Évalué à 2.

                  Pas faux, mais dans ce cas, les octets à la seconde ne sont pas non plus pertinents d'un point de vue utilisateur, puisque c'est la vision au niveau IP, il reste à ajouter le TCP (ou l'UDP), le http, les websockets, etc par dessus.

                  • [^] # Re: Risque ?

                    Posté par (page perso) . Évalué à 3.

                    Ça dépend. Quand on dit que ton réseau est 1 Gbit/s cela prend en compte les en-têtes Ethernet, IP, TCP, HTTP, etc. Tout ceci est déjà pris en compte. C'est-à-dire qu'au niveau applicatif le maximum théorique d'une telle connexion est de 1 Gbit/s moins la taille de toutes les entêtes de la pile réseau employée par requête multipliée par le nombre de requêtes dans la seconde.

                    Donc je ne vois pas où tu veux en venir.

                    • [^] # Re: Risque ?

                      Posté par . Évalué à 2.

                      Je crois plutôt que les opérateurs misent sur l'absence de compétences techniques des utilisateurs pour les manipuler avec des chiffres trompeurs. Je ne compte plus le nombre de gens qui ne comprennent pas les données fournies par leurs FAIs.

                      Quand on dit que ton réseau est 1 Gbit/s cela prend en compte les en-têtes Ethernet, IP, TCP, HTTP, etc.

                      Perso, quand je souscrit à un réseau, c'est le débit réel du réseau qui m'intéresse. Dans le cas du réseau internet, c'est donc juste le débit à partir d'IP: je suis censé être libre d'utiliser du TCP, de l'UDP, ou les autres.
                      Du coup, penses-tu que la plupart des gens ont conscience du ratio utile des protocoles qu'ils utilisent? Je ne le pense pas.
                      Je pense, et si je pouvais me tromper ça serait génial, que les gens pensent qu'un fichier de 1Gio, avec une connection de 1Mio/s, ça se télécharge en 1000 secondes, et qu'ils appliquent cette "règle" élémentaire simple à tous leurs débits.

                      Alors que, justement, quand tu passes par http, tu ajoutes des méta-données, et utiliser un truc en websocket s, bâti sur http, en ajoute encore plus, et du coup le coût réel est au final différent.
                      Alors que je suis quasi sûr que les FAIs regardent eux le débit réel. Et si on veux un truc réellement neutre, ben, il faut s'abstraire des protocoles de haut niveau donc IP me semble faire partie.

                      • [^] # Re: Risque ?

                        Posté par (page perso) . Évalué à 3.

                        Je crois plutôt que les opérateurs misent sur l'absence de compétences techniques des utilisateurs pour les manipuler avec des chiffres trompeurs. Je ne compte plus le nombre de gens qui ne comprennent pas les données fournies par leurs FAIs.

                        Ce n'est pas parce l'utilisateur ne comprend pas les chiffres indiqués qu'ils sont trompeurs. Au contraire même, parfois c'est dans son intérêt d'avoir une mesure physique standard qui facilite les comparaisons entre opérateurs et qui évitent justement la tromperie.

                        Un exemple bien connu : l'énergie où tout repose sur le concept d'un kWh. Unité peu glamour, souvent mal comprise mais qui permet sans problème de comparer les fournisseurs d'énergie et de calculer l'impact d'un appareil électrique sur sa facture.

                        Perso, quand je souscrit à un réseau, c'est le débit réel du réseau qui m'intéresse. Dans le cas du réseau internet, c'est donc juste le débit à partir d'IP

                        IP 4 ou 6 ? Ce qui a une incidence non nulle (la taille de l'en-tête n'est pas identique).
                        Je pense qu'il est délicat d'exprimer justement la taille maximale du tuyau loué en fonction d'une technologie vouée à évoluer. Présenter le chiffre physique comme c'est fait aujourd'hui évite le risque de tromperie car l'un utilise l'IPv6 et l'autre l'IPv4 dans le calcul commercial. Cela permet aussi de comparer l'évolution de la chose dans le temps car indépendant de la technologie employée.

                        je suis censé être libre d'utiliser du TCP, de l'UDP, ou les autres.
                        Du coup, penses-tu que la plupart des gens ont conscience du ratio utile des protocoles qu'ils utilisent? Je ne le pense pas.

                        Justement, c'est là où tu es bancal. Tu dis que les histoires d'en tête protocolaires c'est trop complexe pour l'utilisateur moyen (et je suis d'accord) mais tu veux que l'opérateur te communique un chiffre au niveau de l'IP. C'est trompeur car cela ne prend pas en compte les en-têtes des protocoles au dessus (ce que l'utilisateur ne saura pas mesurer lui même de toute façon, donc au niveau IP il ne gagne rien) mais c'est pire car tu rends ta mesure dépendant d'une technologie. Or l'utilisateur avancé, comme toi, est capable de mesurer facilement l'impact à partir de la valeur commerciale.

                        Bref, justement, ta proposition va amener de la confusion à l'utilisateur, sans rien lui apporter, tout ça pour t'épargner quelques calculs bateaux.

                        Je pense, et si je pouvais me tromper ça serait génial, que les gens pensent qu'un fichier de 1Gio, avec une connection de 1Mio/s, ça se télécharge en 1000 secondes, et qu'ils appliquent cette "règle" élémentaire simple à tous leurs débits.

                        Mais ta solution ne règle pas cette question, car il y a toujours HTTP, TCP et tout à prendre en compte. Que le FAI ne peut pas faire à ta place. Le mieux qui peuvent faire c'est de présenter des calculs du genre combien de temps pour télécharger un film ou des musiques d'une taille donnée. Mais c'est biaisé car lié à la technologie employée (IPv4 vs IPv6, TCP vs UDP, HTTP vs Torrent, etc.).

                        Alors que je suis quasi sûr que les FAIs regardent eux le débit réel.

                        Tout à fait, et comme je l'ai expliqué, c'est très bien ainsi. C'est la meilleure solution.

                        • [^] # Re: Risque ?

                          Posté par . Évalué à 2.

                          Je me suis très mal exprimé, je crois.

                          À la base, je répondais à ceci:

                          Parce que le baud ne donne aucune information pratique pour l'utilisateur du réseau. Tu peux avoir un réseau avec 10 bauds par secondes et un débit de 12 bits par secondes (ou l'inverse). À moins de connaître précisément la technologie utilisée, le baud n'est pas une information pertinente.

                          Mon point de vue est qu'utiliser des bits par seconde, ou parfois, de manière un peu confuse (parce que quand c'est un document ou une boîte dont les écrits sont en anglais, je n'ai jamais la certitude de quelle unité est utilisée moi, je confesse faire partie des gens qui ne se rappellent pas systématiquement de quelle lettre doit être en majuscule ou en minuscule dans une unité), des bytes per second (unité qui, au passage, ne veux rien dire puisque la taille d'un byte n'est pas nécessairement de 8 bits), est une unité confuse, alors qu'il existe le baud, qui lui me semble l'unité la plus pertinente pour définir un débit d'information sur une ligne, parce que justement décorrélé de toute notion de protocole, si je me trompe pas.

                          Et je trouve que, justement, avec les b/s, l'utilisateur non averti à trop la tentation de croire que ce qu'il voit dans son outil pour mesurer est une mesure comparable à ce qui est écrit sur son contrat (en oubliant au passage le fait que dans un téléchargement, il n'y a pas que son boîtier à lui qui est impliqué, mais c'est un autre problème).

                          J'ai l'impression qu'avec le baud, c'est plus explicite que les protocoles utilisés ont un impact sur la charge utile réellement transportée, qu'avec le b/s ou le B/s. Je me trompe peut-être, ou peut-être que je n'ai pas compris ce que Xavier et toi voulez dire (pas improbable du tout pour le coup).

                  • [^] # Re: Risque ?

                    Posté par (page perso) . Évalué à 2.

                    au niveau IP, il reste à ajouter le TCP (ou l'UDP), le http, les websockets, etc par dessus.

                    Il ne manque plus qu'un tunnel IPX, et on peut faire tourner des clients Netware sous DOS dans un émulateur 8088 écrit en Node.js ? mais où va-t-on ne pas s'arreter ?

                    * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

                    • [^] # Re: Risque ?

                      Posté par . Évalué à 3.

                      Je dois être idiot, mais je ne comprend déjà pas l'intérêt des websockets, qui sont pour moi une aberration.

                  • [^] # Re: Risque ?

                    Posté par (page perso) . Évalué à 3.

                    Pas faux, mais dans ce cas, les octets à la seconde ne sont pas non plus pertinents

                    Non, on parle de bits à la seconde. C'est plus pertinent. Après, je parlais au niveau utilisateur du média. Par exemple, je branche mon câble Fast Ethernet et je m'attends à 100Mbps et je peux le comparer à la 4G à 150Mbps. Tandis que si l'Ethernet fait 120M bauds par secondes comparé à la 4g qui fait 105 bauds par secondes (chiffres complètement au hasard). Je ne peux pas comparer. En plus, ça ne me donne aucune idée sur mon débit effectif. Alors que les headers que tu donne, il sont les mêmes en 4G et en Ethernet.

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: Risque ?

                      Posté par . Évalué à 2.

                      On a du mal se comprendre.

                      Un baud, c'est justement une unité de débit, pas de volume. Du coup, le "baud par seconde" c'est… inutile, les bauds étant de base une unité de volume de données transmises à la seconde.

                      Je pense que l'on s'est mal compris, pourrais-tu infirmer cette idée ou expliciter un peu plus ton opinion?

                      • [^] # Re: Risque ?

                        Posté par (page perso) . Évalué à 4.

                        Effectivement, j'ai ajouté par seconde par erreur mais le Baud n'est pas une unité de débit mais un nombre de signe par seconde. Par exemple, le protocole v90 a un débit de 56kbps mais seulement 8000 bauds.

                        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                        • [^] # Re: Risque ?

                          Posté par . Évalué à 2.

                          Ok, je pense que je vois ce que tu veux dire. Du coup, j'avais tort, merci de m'avoir détrompé.

                • [^] # Re: Risque ?

                  Posté par (page perso) . Évalué à 3.

                  Du temps où j'utilisais un modem analogique, je m'étais intéressé à ce rapport entre bauds et bit/s. Voilà ce que j'en ai retenu et qui, pour ce que j'en ai compris, ne semble par être contradictoire avec ce qu'on trouve sur Wikipedia.

                  Le baud est l'unité de mesure du nombre de variations par seconde d'un signal. Si la variation consiste en deux valeurs différentes d'une seule grandeur physique, alors on a un nombre de bit/s transmis équivalent aux bauds. Si la grandeur physique variait sur plus de deux valeurs, alors chaque variation du signal permet d'encoder plus d'un seul bit, et le nombre de bit/s est alors supérieur aux bauds (mais au prix d'une plus grande sensibilité du signal aux parasites). On pouvait également faire varier plus d'une grandeur physique du signal à la fois, toujours dans le but d'encoder plus d'un bit par variation du signal.

                  Le signal transmis par les modems analogiques (et ça vaut, je pense, aussi pour l'xDSL et la fibre) est caractérisé par trois grandeurs physiques : la fréquence, l'amplitude, et la phase. Rien qu'en faisant varier (moduler est le terme consacré, d'où la désignation de mo(dulateur)dem(odulateur), mais là, je ne vous apprend rien…) en même temps ces trois grandeurs sur seulement deux valeurs, on multipliait le débit du signal en bit/s par trois par rapport aux bauds (chaque grandeur physique pouvant encoder un bit). Débit que l'on pouvait encore accroître, comme écrit préalablement, en augmentant le nombre de valeurs autorisées par grandeur physique. Donc, normalement, le nombre de bits par secondes ne peut être inférieur aux bauds.

                  Freelance en ingénierie informatique.

                  • [^] # Re: Risque ?

                    Posté par (page perso) . Évalué à 4.

                    Donc, normalement, le nombre de bits par secondes ne peut être inférieur aux bauds.

                    Si, ça peut arriver si le protocole utilise des signaux pour son fonctionnement. Par exemple, tu as un protocole qui fonctionne de la manière suivante: "Je vais envoyé un bit" "voilà le bit" "le bit a été envoyé", tu as 3 signaux pour un bit de donnée. Donc si tu as 3 bauds, tu as 1 bps.

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: Risque ?

                      Posté par (page perso) . Évalué à 1.

                      Ça dépend des bits considérés. Je me référais à ceux au plus proche du matériel, ceux que l'on peut déduire du signal électrique qui transite par le câble reliant le modem à l'appareil émetteur/récepteur des données. Le débit de ces bits devrait être pour le moins égal aux bauds, évidemment seulement lors des périodes durant lesquelles il y a émission/réception de données.

                      Freelance en ingénierie informatique.

            • [^] # Re: Risque ?

              Posté par (page perso) . Évalué à 3.

              En quoi la norme SI (même pas ISO) est-elle débile ?

              Pourquoi utiliser un mélange de puissances de 10 et de puissances de 2 ? Quel est l'avantage de ce mélange, en fait ? Dans 99,9% (statistique au doigt mouillé particulièrement fiable, évidemment), on parle de toute façon en Mo, Go voire To, avec une valeur exacte qui ne s'exprime facilement ni en puissances de 2, ni en puissances de 10.

              • [^] # Re: Risque ?

                Posté par . Évalué à 4. Dernière modification le 22/01/18 à 21:21.

                Dans 99,9% (statistique au doigt mouillé particulièrement fiable, évidemment), on parle de toute façon en Mo, Go voire To

                Dans 99,9% des cas on parle de Mio, Gio, Tio justement… La commande df me donne des Mio,Gio,… par défaut… Et comme personne ne prend le soin de mettre ce satané i quand il écrit, on se retrouve avec quelque chose d’équivoque souvent.

                Je reconnais que j’y ai été un peu fort avec le mot « débile », l’homogénéité des « préfixes SI » est une raison défendable… je la trouve bien faible quand même…

                Quel est l'avantage de ce mélange, en fait ?

                Quel était son inconvénient pour qu’on éprouve le besoin de changer ?

                • [^] # Re: Risque ?

                  Posté par (page perso) . Évalué à 2. Dernière modification le 22/01/18 à 23:17.

                  Je voulais bien sûr dire que de toute façon on utilise des préfixes, avec plein de chiffres après la virgule qui sont perdus dans la nature. Bref, l'argument d'une pseudo-exactitude des Tio/Gio/… ne tient pas debout.

                  Quel était son inconvénient pour qu’on éprouve le besoin de changer ?

                  • garder le vrai sens des préfixes SI
                  • avoir des calculs plus simples et sans ambiguïté de façon générale
                  • avoir des conversions qui soient simplement… exactes (et oui : on a 1,023 kio = 1 047,55 o… ou 1 047 o = 1,022460[…] kio : conversion exacte impossible dans les deux cas)
                  • permettre des conversions et des comparaisons d'un coup d'œil (peux-tu comparer 0,49 Tio et 500 Gio ? )

                  Au final, on a quand même une habitude qui n'apporte pas grand-chose, voire rien du tout (les *io) face à un système (le SI) largement éprouvé, répandu et efficace.

                  • [^] # Re: Risque ?

                    Posté par . Évalué à 3.

                    Merci pour ta réponse, tu m’as presque convaincu :)

                    Pour le fait que l’écart augmente, est-ce si gênant ? Bon, je reconnais que ça aurait peut-être poser un problème avec des préfixes de plus en plus grands. Ça aurait commencé à ne plus être « presque naturel », mais bon, les nombres très grands ou très petits sont de toutes façon pas facile à se représenter.

                    peux-tu comparer 0,49 Tio et 500 Gio

                    Le premier est plus grand _o_ C’est vrai, avec des préfixes décimaux (SI) je peux me rendre compte qu’il y a 1 Go d’écart… pas besoin de sortir la calculatrice. Sinon on peut se contenter de l’approximation mentale 0,5 Tio = 512 Gio… le calcul est pas trop dur ensuite.

                    Bwallé, je commence à être de mauvaise foi ;) L’organisation a sûrement choisi la meilleure solution, malgré mon impression personnelle.

                    Bref, l'argument d'une pseudo-exactitude des Tio/Gio/….

                    Ah non moi c’est par amour pour la base 2 :)

                  • [^] # Re: Risque ?

                    Posté par . Évalué à 3.

                    avoir des calculs plus simples et sans ambiguïté de façon générale

                    Quand on doit vraiment calculer il faut le faire à l’octet (ou au block) près de toute façon…

      • [^] # Re: Risque ?

        Posté par . Évalué à 2.

        Je n'ai pas l'impression qu'il soit possible d'extraire volontairement et simplement des données sensibles (données persos, mots de passe ou clé cryptographiques) sur demande.

        Pour Meltdown je pense que si c'est faisable et que cela a ete montre. Pour Spectre, d'apres ce que j'ai lu et compris, c'est theoriquement faisable mais, aujourd'hui, il n'y a pas de preuve pratique.

    • [^] # Re: Risque ?

      Posté par . Évalué à 3.

      Il n'y a pas que toi qui l'utilise. Il y a aussi tous les sites qui font tourner du javascript dans ton browser.

  • # Aide à l'attaquant ?

    Posté par (page perso) . Évalué à 8.

    Ça paraît super pratique. Par contre, si l'information est disponible pour n'importe quel utilisateur de la machine, ça donne une aide non négligeable pour savoir quoi attaquer (y a même pas besoin de tester la fonction ou de vérifier la version du noyau).

    • [^] # Re: Aide à l'attaquant ?

      Posté par . Évalué à 2.

      C'est vrai que je ne comprend pas trop pourquoi c'est pas restreints a un acces root uniquement ces infos.

      • [^] # Re: Aide à l'attaquant ?

        Posté par (page perso) . Évalué à 9.

        Pas convaincu que de masquer l'information soit efficace.
        Avec la version du noyau normalement tu as une bonne idée de la surface d'attaque. Un uname -a peut donc fournir l'information nécessaire.

        Sans compter que la sécurité par l'obscurité n'est pas efficace de manière générale. Miser là dessus me paraît un brin cavalier.

        • [^] # Re: Aide à l'attaquant ?

          Posté par (page perso) . Évalué à 10.

          Je suis d'accord que la sécurité par l'obscurité n'est pas la solution ultime. En même temps:

          • sur un Apache httpd, on peut régler ServerTokens Prod, ServerSignature Off
          • sur un PHP, on peut régler expose_php = Off
          • sur un Nginx, on peut avoir server_tokens off;
          • et sur un sshd, on n'affiche pas "Ici il n'y a que Alice et Bob qui ont des comptes, alors ne vous fatiguez pas à tester les autres logins".
          • [^] # Re: Aide à l'attaquant ?

            Posté par (page perso) . Évalué à 4.

            et sur un sshd, on n'affiche pas "Ici il n'y a que Alice et Bob qui ont des comptes, alors ne vous fatiguez pas à tester les autres logins".

            Si tu voulais rester cohérent dans tes exemples, tu aurais continué sur l’affichage de la version et justement :

            $ echo | nc host 22
            SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u2
            Protocol mismatch.
            
            • [^] # Re: Aide à l'attaquant ?

              Posté par (page perso) . Évalué à 3.

              Si tu voulais rester cohérent dans tes exemples, tu aurais continué sur l’affichage de la version et justement :

              Que tu peux désactiver aussi, comme mettre ServerToken à prod.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Aide à l'attaquant ?

          Posté par . Évalué à 9.

          Je pense qu'il y a une difference entre laisser l'information disponible a l'administrateur et la laisser disponible a tout le monde.

          Tu mets en acces libre /etc/shadow? Si non pourquoi? C'est de la securite par l'obscurite.

          • [^] # Re: Aide à l'attaquant ?

            Posté par (page perso) . Évalué à 3.

            Tu mets en acces libre /etc/shadow? Si non pourquoi? C'est de la securite par l'obscurite.

            Sauf que l'utilisateur lambda n'a pas de moyen d'accéder aux infos de /etc/shadow en dehors de l'accès au fichier lui même.

            Concernant les failles, à priori, connaître la version du noyau est suffisant. Information que tu retrouves partout : chargeur de démarrage, démarrage du noyau (ou dmesg / journalctl une fois lancée), uname -a, etc.

            Bref, ajouter cette information ne fait gagner que très peu de temps à l'attaquant, et il ne va probablement gagner aucune information supplémentaire qu'avec les moyens que j'ai listé plus haut. Par contre cela simplifie grandement la visibilité de la situation pour l'administrateur et l'utilisateur de la machine.

            • [^] # Re: Aide à l'attaquant ?

              Posté par . Évalué à 2.

              Par contre cela simplifie grandement la visibilité de la situation pour l'administrateur et l'utilisateur de la machine.

              Il ne faut pas non plus exagérer, ce serait juste un sudo à rajouter.

              • [^] # Re: Aide à l'attaquant ?

                Posté par (page perso) . Évalué à 3.

                L'utilisateur n'est pas forcément un sudouser donc oui c'est bien plus facile pour lui que de devoir chercher sur le web une liste des noyaux concernés ou pas par la faille. Surtout que l'utilisateur n'est pas forcément un expert.

                • [^] # Re: Aide à l'attaquant ?

                  Posté par . Évalué à 4.

                  En quoi un utilisateur, non admin, du system peut avoir besoin de connaitre ces informations?

                  Il a des possibilite pour mitiger le probleme en mode user que l'admin n'a pas, parceque moi il ne me semble pas mais bon peut etre que si…

                  • [^] # Re: Aide à l'attaquant ?

                    Posté par (page perso) . Évalué à 6.

                    Je trouve cela sain que l'utilisateur puisse connaître le degré de sécurité de sa machine même s'il n'a pas les possibilités de résoudre cela lui même directement. Sauf en avertissant son administrateur système préféré par exemple.

                    En tout cas je ne trouve pas non plus de justification qui rende cette divulgation un problème. Si ce n'est pas un problème particulier, autant l'afficher. Cela me paraît normal.

                    Si tu veux on peut discuter de tout le /sys ou /proc où bon nombre d'infos ne sont pas pertinents pour la quasi totalité des gens, est-ce une raison suffisante pour masquer cela ? Bof

                    • [^] # Re: Aide à l'attaquant ?

                      Posté par . Évalué à 1.

                      Je ne suis pas d'accord mais bon c'est probablement parce que je suis biaisés. Les systèmes que j'utilise ont des centaines d'utilisateurs et dans le tas il y a des script kiddies et les aider avec ce genre d'information je ne pense pas que cela soit génial. Enfin bon c'est mon opinion et elle est probablement pas bonne.

                      • [^] # Re: Aide à l'attaquant ?

                        Posté par (page perso) . Évalué à 4.

                        Comme je l'ai dit, l'information que les personnes malveillantes veulent est disponible quoiqu'il arrive. Tu ne vas pas les retenir longtemps en cachant les fichiers en question.

                        De plus, étant donnée les failles en question, je doute qu'un script kiddie puisse faire quoique ce soit. Cela demande quand même des compétences, l'outillage et de l'analyse.

                      • [^] # Re: Aide à l'attaquant ?

                        Posté par . Évalué à 2.

                        Tu peux utiliser selinux (ou j'imagine apparmor) pour changer le contexte de ces fichiers. Ça va te paraître con de devoir utiliser une couche supplémentaire pour sécuriser un truc qui te paraitrait plus simple mais bon c'est toujours possible de sécuriser cette partie.

                      • [^] # Re: Aide à l'attaquant ?

                        Posté par (page perso) . Évalué à 4.

                        Le script kiddie il ne va pas chercher à savoir si le système est vulnérable avant de lancer son script, il va lancer le script tout court, et si c’est vulnérable c’est gagné. L’attaquant ne vas pas regarder /sys/machin pour savoir si son exploit va marcher, il va lancer directement l’exploit, et si ça marche il récoltera directement ce qui l’intéresse. Récolter les valeurs de /sys/machin ça n’apporte rien du tout à l’attaquant et ça ne l’intéresse pas. Et si /sys/machin ne dit rien bah l’attaquant passera directement à la première étape : lancer l’exploit. Cacher cette information ne sert à rien, ni l’exploit ni l’attaquant n’en ont besoin : ils exploitent [haha] directement.

                        Par contre l’utilisateur, l’administrateur (qui est aussi un utilisateur) n’a pas envie de devoir lancer un exploit pour savoir où il en est, se rassurer ou faire sa supervision.

                        ce commentaire est sous licence cc by 4 et précédentes

            • [^] # Re: Aide à l'attaquant ?

              Posté par . Évalué à 2.

              Concernant les failles, à priori, connaître la version du noyau est suffisant.

              Si je ne m'abuse, il y a moyen de désactiver les patchs avec des paramètres en ligne de commande (ligne passée au noyau par le boot, hein, pas via un prompt urxvt) donc, non, la version ne suffit pas (quant à pourquoi désactiver, à priori, me semble que pour certains usages les correctifs peuvent avoir un impact non négligeable sur les perfs, même si ça sera pas le cas de nos machines de bureau).

              • [^] # Re: Aide à l'attaquant ?

                Posté par (page perso) . Évalué à 3.

                Suffit donc de lire le fichier /proc/cmdline qui est accessible à tous, ou alors lire les sorties de dmesg ou de journalctl (de même, c'est accessible à tous) pour avoir cette information.

                Bref, rien de très sorcier. Les exploitants des failles dont on parle sont je pense assez compétent pour être capables de récolter ces informations très rapidement.

              • [^] # Re: Aide à l'attaquant ?

                Posté par . Évalué à 2.

                passée une certaine version de noyau tu sais généralement quelles failles sont déjà colmatées. Autant il y'a pas mal de noyaux avec des patches backportés de version supérieures, autant je ne connais pas de cas de noyau sur lesquelles ont aurait enlevé du code corrigeant des bugs volontairement.

      • [^] # Re: Aide à l'attaquant ?

        Posté par . Évalué à 3.

        J'sais pas.

        Si tu restreints à root, t'es obligé de faire des pirouettes avec des outils comme sudo pour que des outils de monitoring accèdent l'info facilement. Ça parait anodin mais plus une config sudo est dense plus tu risques d'y introduire "des failles" par erreur, manque d'expérience ou ignorance. J'ai vu des gens qui faisaient n'importe quoi avec sudo.

    • [^] # Re: Aide à l'attaquant ?

      Posté par . Évalué à 3.

      Il y a ça, mais aussi la question de la pertinence: déjà, les vulnérabilités sont adressées par leurs noms de baptême et non leurs CVE (je suppose qu'elles en ont?) donc au niveau maintenance sur le long terme ça risque d'être un peu chiant.
      Et si c'est juste pour spectre et meltdown, alors c'est dommage, mais d'un autre côté, maintenir ce genre de choses pour l'ensemble des vulnérabilités risque d'être très coûteux en temps humain et aussi en code sur la longueur.

      Du coup, je ne suis pas convaincu du tout que ce soit une bonne idée. Pour les gens soucieux des CVE potentielles sur leurs systèmes, il me semble qu'il existe déjà des paquets pour ce type de problématiques (celui de debian ne semble pas contenir "cve" dans son nom, ou alors aucun paquet ne me rappelle des souvenirs).

      • [^] # Re: Aide à l'attaquant ?

        Posté par . Évalué à 2. Dernière modification le 22/01/18 à 15:57.

        Je trouve effectivement que de référencer les CVE aurait été plus pertinent. Maintenant ça peut être un truc intéressant de façon sporadique. Genre le jour ou meldown et spectre sont de l'histoire ancienne ça pourra sûrement être nettoyé facilement. et si une autre faille majeure arrive ça peut aussi être utilise.

        Seul l'avenir pourra nous dire si c'est bien ou pas géré par les mainteneurs des différentes versions des noyaux. Les distributions gardent la liberté de retirer cette fonctionnalité si ça ne leur plaît pas.

      • [^] # Re: Aide à l'attaquant ?

        Posté par (page perso) . Évalué à 7.

        Et si c'est juste pour spectre et meltdown, alors c'est dommage, mais d'un autre côté, maintenir ce genre de choses pour l'ensemble des vulnérabilités risque d'être très coûteux en temps humain et aussi en code sur la longueur.

        D’un autre côté, il n’est question ici que des vulnérabilités affectant le CPU (pas le noyau ou les logiciels tournant autour), on peut espérer que ces vulnérabilités ne seront pas trop nombreuses (même si maintenant que quelqu’un a montré la voie, on peut s’attendre à ce que pas mal de gens se mettent activement à chercher ce type de vulnérabilités, et en trouvent).

        Au passage, c’est justement parce qu’il s’agit de vulnérabilités matérielles que je trouve approprié que le noyau se charge d’en exposer l’existence à l’espace utilisateur. Selon moi ça fait partie de son rôle, de la même manière qu’il expose les caractéristiques et fonctionnalités du CPU dans /proc/cpuinfo.

        • [^] # Re: Aide à l'attaquant ?

          Posté par . Évalué à 1.

          L'argument se tient.
          Mais, dans ce cas, pourquoi je n'ai pas d'informations précises dans mon /proc/cpuinfo quant au CPU?
          Je veux dire, on sait que l'algo de prédiction (hyper bas level quand même) est vulnérable à des failles actuelles et que le kernel est patché (ou pas) en conséquence (et je doute que la vulnérabilité soit testée par le noyau, à mon avis, c'est juste du bon gros hardcode pas propre, à vérifier) mais on ne sait même pas combien de niveau de cache il y a, ni leur répartition par coeur, ni… la liste est longue. D'ailleurs, elle inclue la longue liste des firmware plus ou moins planqués sur la carte mère ou le CPU, qui peuvent receler des backdoors et failles bien pire que spectre et meltdown.

          Pour moi, le rôle du kernel n'est pas d'informer sur les failles du hard, mais d'en permettre l'usage (du hard, hein) de manière uniforme sans (trop) s'inquiéter de comment fonctionne le matériel (parce que je pense qu'il est quand même bon de connaître l'archi globale d'un PC, info qui n'est d'ailleurs dans aucune page de manuel de mon système, à moins que je ne sois passé à côté…).
          Ça, et d'être performant sans mentir (et je crains qu'un jour, mon kernel pas compilé à la main mais chopé d'une distro ne mente, si je me fie à ces informations qui seront potentiellement corrigées dans 10ans).

          • [^] # Re: Aide à l'attaquant ?

            Posté par (page perso) . Évalué à 6.

            Mais, dans ce cas, pourquoi je n'ai pas d'informations précises dans mon /proc/cpuinfo quant au CPU?

            Ça y est :

            bugs : cpu_meltdown spectre_v1 spectre_v2

            Après cela ne signifie pas où en est la correction, mais cela liste les erreurs du matériel. Tu y as accès.

            et je doute que la vulnérabilité soit testée par le noyau, à mon avis, c'est juste du bon gros hardcode pas propre, à vérifier

            Ce n'est pas sale d'établir une liste du matériel concernée (avec éventuellement des jokers sur les id pour une plage complète). C'est même plus fiable et plus performant qu'un test du noyau à chaque démarrage.

            Pour moi, le rôle du kernel n'est pas d'informer sur les failles du hard, mais d'en permettre l'usage (du hard, hein) de manière uniforme sans (trop) s'inquiéter de comment fonctionne le matériel (parce que je pense qu'il est quand même bon de connaître l'archi globale d'un PC, info qui n'est d'ailleurs dans aucune page de manuel de mon système, à moins que je ne sois passé à côté…).

            Le but du noyau est de faire le lien entre le matériel et le logiciel. De la façon la plus exhaustive que possible. C'est aussi une sorte de machine virtuelle pour les logiciels, à priori ton shell n'a pas à se conformer aux specs du matériel mais à ceux de Linux. Linux faisant le lien entre son API et le matériel.

            Donc oui le noyau doit permettre cette abstraction, mais pas que. Parfois tu as envie d'avoir accès à tous les détails de ton matériel pour en retirer certaines fonctionnalités ou plus de performances. Ou même tout simplement savoir ce qui se passe.

            Ces failles ayant un impact (en terme de sécurité ou de performances), il est bon que le logiciel en dessous (et l'utilisateur) en soit conscient ou du moins puisse l'être. Je serais content aussi que le noyau me prévienne si jamais le bogue sur le calcul des flottants de la part d'Intel (pour un processeur des années 90) revienne pour que le logiciel et l'utilisateur soient capables de tirer parti de cette information.

            On est pleinement dans le rôle du noyau.

            • [^] # Re: Aide à l'attaquant ?

              Posté par (page perso) . Évalué à 3.

              si jamais le bogue sur le calcul des flottants de la part d'Intel (pour un processeur des années 90) revienne

              Pour tous les jeunes qui n'ont pas connu ce bug mémorable : essayez d'imaginer une fonction strictement croissante qui peut avoir à un point précis une dérivée négative.

              Enjoy !

              * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

  • # UUoG

    Posté par (page perso) . Évalué à 2.

    grep . /sys/devices/system/cpu/vulnerabilities/*

    Est-ce qu’on ne serait pas face à un Useless Use of Grep ? :)

    • [^] # Re: UUoG

      Posté par (page perso) . Évalué à 10.

      Tu vois un autre moyen pratique d'afficher à la fois le nom de chaque fichier et leur contenu?

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: UUoG

        Posté par . Évalué à 0.

        1. head
        2. tail
        3. find
        4. for

        Membre de l'april, et vous ? http://www.april.org/adherer

        • [^] # Re: UUoG

          Posté par (page perso) . Évalué à 6.

          Aucune de ces solutions ne me semble aussi pratique que grep.

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: UUoG

            Posté par . Évalué à 0.

            Dans ton cas d'usage, head et tail auraient une sortie carrément plus lisible, et find/for permettraient de personnaliser l'affichage autant que tu veux.

            Errare humanum est, perseverare diabolicum

            Membre de l'april, et vous ? http://www.april.org/adherer

            • [^] # Re: UUoG

              Posté par (page perso) . Évalué à 1.

              Le SNR de la commande initiale me semble bien plus élevé que tout ce qui est proposé comme « meilleure solution » en commentaires. Quant au SNR des commentaires…

              YMMV

              Debian Consultant @ DEBAMAX

          • [^] # Re: UUoG

            Posté par (page perso) . Évalué à 2.

            aussi pratique que grep.

            Alors que tout le monde sait que awk est la réponse adaptée.

            * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

  • # Je ne comprends plus rien avec ce titre

    Posté par . Évalué à -9. Dernière modification le 22/01/18 à 18:57.

    C'est le noyau qui et vulnerable ou c'est le processeur ?
    Et concernant les processeurs AMD, ca fonctionne comment ce test ?

    attention chérie ça va moinsser

    • [^] # Re: Je ne comprends plus rien avec ce titre

      Posté par . Évalué à -10.

      Comme par hasard on ce garde bien d'evoquer le cas des processeurs AMD, en mettant tout le monde dans le meme sac a patates Intel.

      Et comme par hasard on devoile la faille au meme moment ou les processeurs AMD tirent leurs epingle du jeu face aux Intel.

      Ca sent l'embrouille et la corruption cette histoire.

      attention chérie ça va moinsser

      • [^] # Re: Je ne comprends plus rien avec ce titre

        Posté par . Évalué à 6.

        Comme par hasard on ce garde bien d'evoquer le cas des processeurs AMD, en mettant tout le monde dans le meme sac a patates Intel.

        Non. Ce n’est pas caché, les processeurs AMD ne sont manifestement pas concernés par Meltdown.

        Cela dit, à la place d’AMD je ne fanfaronerait pas non plus là dessus… Il pourrait leur arriver la même chose demain ! Puis entre acteurs majeurs du marché, ni l’un ni l’autre n’ont intérêt à se livrer une guerre pour y perdre des plumes.

        Les clients d’Intel, c’est à dire d’abord les constructeurs d’ordinateurs, ont plus intérêt à travailler avec Intel pour résoudre ce problème que d’arrêter toute collaboration pour mettre tous leurs œufs chez AMD. Même s’ils le voulaient ça se ferait pas comme ça… essaye d’imaginer ce que ça implique en terme de modification des process…

        Cette faille est impressionnante par son ampleur inégalée mais au niveau de la direction d’Intel, des autres fondeurs, on doit s’attendre à voir encore pire arriver dans les décennies à venir…

        Ou alors c’est le glas qui sonne pour Intel, la fin d’un époque, on va voir Intel disparaître et un petit nouveau venir tenir la corde à AMD. Avec des spécifications ouvertes pourquoi pas ! :)

      • [^] # Re: Je ne comprends plus rien avec ce titre

        Posté par (page perso) . Évalué à 4.

        ARM est affecté par les deux failles, et AMD est affecté par Spectre. Bref, pas de quoi fanfaronner sur telle ou telle marque ici.

        • [^] # Re: Je ne comprends plus rien avec ce titre

          Posté par . Évalué à 2.

          Certains ARM pas tous. Les raspberryPi ne sont pas impactes par exemple:

          https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

          • [^] # Re: Je ne comprends plus rien avec ce titre

            Posté par . Évalué à 0.

            Que la personne qui considere le message precedent m'explique en quoi le message n'est pas pertinent par rapport au journal ou par rapport au message auquel je repond?

            Le lien que je fourni parle de ARM, de Meltdown et de Spectre!

            Mais bon je suis pret a accepter une explication logique.

            • [^] # Re: Je ne comprends plus rien avec ce titre

              Posté par (page perso) . Évalué à 4.

              Peut-être parce que ton commentaire est pertinent, mais ce que tu mentionnes est un cas particulier. Le problème ici, c'est que l'ensemble des fondeurs de processeurs ont sous-estimé les problèmes de sécurité, et plus globalement tous les fabriquants de matériel. Dans les prochains mois, de nouvelles vulnérabilités vont être découvertes. Bref, ce n'est plus le moment de mettre en avant une marque : ils ont tous été "mauvais".

        • [^] # Re: Je ne comprends plus rien avec ce titre

          Posté par . Évalué à 4. Dernière modification le 24/01/18 à 00:05.

          ARM est affecté par les deux failles, et AMD est affecté par Spectre.

          Le truc, si j’ai bien compris, c’est que la faille Spectre s’appuie sur des données (les résultats des exécutions « prédictives » que génère le processeur) qui sont normalement accessibles, lisibles. Donc c’est beau, élégant… Les concepteurs du processeur auraient pu, certes, imaginer que ça puisse arriver et décider de protéger cet espace mémoire. Ils ne l’ont simplement pas fait, jugeant que le bénéfice/risque était trop faible.

          A contrario, Meltdown exploite le fait que le processeur expose une partie de sa mémoire alors qu’il n’est pas censé le faire. Le processeur se comporte d’une manière erronée sous certaines conditions, c’est donc différent de Spectre. Meltdown fait forcément plus « tâche » que Spectre pour cette « simple » raison.

          En espérant ne pas raconter trop de conneries, on me corrigera je l’espère si c’est le cas.

          • [^] # Re: Je ne comprends plus rien avec ce titre

            Posté par (page perso) . Évalué à 3.

            Les concepteurs du processeur auraient pu, certes, imaginer que ça puisse arriver et décider de protéger cet espace mémoire. Ils ne l’ont simplement pas fait, jugeant que le bénéfice/risque était trop faible.

            Peut-être que ça ne leur est pas venu à l'esprit une seconde ? Dans ma jeunesse, j'ai pas mal bossé sur les processeurs (bitslice amd29) pour savoir que c'est le genre de chose à laquelle tu ne penses pas.

            Les temps changent…

            * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

    • [^] # Re: Je ne comprends plus rien avec ce titre

      Posté par . Évalué à 2. Dernière modification le 22/01/18 à 20:19.

      C’est plutôt le processeur… On peut se servir des trucs qu’il exécute en avance « au cas où pour gagner du temps », pour deviner des informations auxquelles on ne devrait pas avoir accès normalement. Le noyau peut « boucher » cette faille. Au prix d’une perte de performance qui peut aller jusqu’à 15% si je ne m’abuse… Il y a des usages pour lesquels ça ne va pas être neutre à mon avis…

      AMD est aussi concerné par la faille Spectre. C’est Meltdown, un autre type de faille, qui ne concerne « que », potentiellement, tous les processeurs Intel (sauf certains Atom, etc…) fondu après 1995…

      C’est vrai que les deux ont été rendues publiques en même temps, donc ça crée de la confusion…

      Wikipédia FR propose des articles sur ces deux failles, comme toujours assez accessible, c’est de la vulgarisation, avec des liens intéressants pour rentrer plus en avant dans le sujet.

      Je viens de découvrir que la faille avait même un logo (enfin sur Wikipédia au moins) mais je sais qu’il y a un site dédié pour chacune des failles. Elles méritent bien ça…

  • # Retpoline

    Posté par . Évalué à 6.

    Un mot qu’il est nouveau on dirait (il l’est pour moi en tous cas)…

    Extrait de la top réponse à https://stackoverflow.com/questions/48089426/what-is-a-retpoline-and-how-does-it-work

    As far as I can piece this together from the limited information at the moment, a retpoline is a return trampoline that uses an infinite loop that is never executed to prevent the CPU from speculating on the target of an indirect jump.

    • [^] # Re: Retpoline

      Posté par (page perso) . Évalué à 6.

      L'explication est un peu nulle. Un retpoline consiste à remplacer un jump conditionnel par un push d'une adresse (variant selon la condition) suivi d'un ret (qui saute à l'adresse sur la pile). Le ret sert normalement à implémenter un retour de fonction. Ce mécanisme permet de contourner l'exécution spéculative car ce sera toujours le même choix qui sera fait par le processeur lors de la spéculation. L'attaquant ne peu plus contrôler la spéculation.

  • # Cas des VPS, AWS et autres solutions virtualisées

    Posté par (page perso) . Évalué à 4.

    Comment ça ce passe dans le cas des architectures virtualisées ? Patcher l'hyperviseur suffit pour isoler les machines virtuelles ?

    Si ce n'est pas le cas, mettre à jour les machines virtuelles ne suffira jamais : On pourra toujours être victime d'un autre client malveillant qui loue une machine virtuelle, se retrouve sur la même machine physique que nous, et fait tourner volontairement un OS lui permettant d'exploiter la faille.

    • [^] # Re: Cas des VPS, AWS et autres solutions virtualisées

      Posté par . Évalué à 3. Dernière modification le 23/01/18 à 13:52.

      Vu que c'est une attaque au niveau CPU, que ce soit virtualise ou pas ne change rien.

      En ce qui concerne Meltdown c'est faisable par le kernel (au prix de perte de perf) par contre Spectre c'est la grosse question. A priori par des mesures dite de "mitigations" mais sinon par une mise jour du microcode mais la c'est pas la joie pour le moment.

      Oui le probleme est important, tres important. Tous les systemes cloud sont impacte et une image peut recuperer des infos sur les autres.

      (corrigé moi si j'ai rien compris :) )

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.