Renault a écrit 7255 commentaires

D'ailleurs l'ARCEP (qui fait un boulot colossal et pertinent dans l'ensemble) a un observatoire consacré à ce sujet : https://www.arcep.fr/index.php?id=13169

Cela permet d'avoir une vue d'ensemble de la situation française et de constater que cela évolue bien.

Beaucoup appareils que nous possédons fonctionnent en IPv4 seulement.

Je ne sais pas où tu vis, mais tous les équipements et systèmes vendus dans le commerce aujourd'hui, et depuis de nombreuses années d'ailleurs (à part de rares exceptions ?) sont compatibles IPv6. Même les boxs des FAI.

Le plus gros problème vient bien entendu de la mise à disposition de l'IPv6 par les opérateurs car cela demande un gros chantier en interne. Mais en France la situation se débloque peu à peu. En Belgique l'opérateur national Proximus (qui détient environ 50% du marché fixe) a activé l'IPv6 pour tous, rendant la Belgique numéro 1 en pénétration de la technologie.

Mais si pour le fixe la situation progresse plutôt rapidement ces derniers temps, le mobile est encore à la traîne, je ne connais pas d'opérateurs européens le faisant (ni même dans le monde en fait) et il ne semble pas y avoir des expérimentations en ce sens.

Selon Google, une requête sur 5 se fait en IPv6, ce n'est pas si mal : https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption&tab=ipv6-adoption

Par contre, qui sera le premier opérateur à ne fournir que de l'IPv6 et quand ? Cela risque d'être long d'arriver à ce résultat.

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

C'est plus du tout pareil que :

Je parlais de la représentation accessible aux OS. Que l'UEFI travaille sur ces données ou non est une question totalement indépendante.

Le problème c'est que ce genre de chose ne sert à rien, ça ajoute beaucoup de complexité pour rien.

La méthode simple (qui marche souvent, à savoir faire UTC + fuseau horaire + décalage d'heure d'été) ne prend que quelques lignes et apparemment quelques octets seulement pour sauvegarder ces infos. Très compliqué en effet.

La véritable difficulté c'est de faire une fonctionnalité parfaite, mais apparemment personne ne s'en préoccupe outre mesure. Et sans mises à jour régulière c'est voué à l'échec.

ça sera 1000x mieux qu'une interface passé au google-translate

Comme beaucoup d'UEFI sont programmés en Asie, en réalité c'est l'anglais qui est une traduction. :-)

Je comprend bien que l'UEFI permet une abstraction qui standardise et fait qu'on peut installer n’importe quel OS sur n’importe quel PC; mais l'UEFI n'as pas besoin d'être un OS pour faire ça.

Honnêtement tu te focalises sur des détails de l'UEFI, c'est quand même assez fou. L'UEFI fait beaucoup de chose bien plus complexes (tout comme le BIOS en son temps) c'est dans l'ordre des choses que ce soient des OS à part entière. D'ailleurs NERF semble les remplacer par du noyau Linux, preuve que cela fait sens.

Tu sais que GRUB, U-boot et tout qui ne sont que des chargeurs de démarrage sont également d'une complexité importante ? Bah oui, initialiser le matériel, gérer des systèmes de fichier, de la cryptographie, du réseau, etc. c'est du gros boulot.

Merci je sais très bien la difficulté de représenter le temps, je suis d'ailleurs en plein dedans.

Mais comme mentionné dans d'autres sujets, parfois il vaut mieux quelque chose qui fonctionne bien pour 90% des cas et dont le problème pour les autres est mineurs que de n'avoir rien du tout.

Et comme cela a été indiqué, l'UEFI peut jouer avec ces données pour en tirer quelque chose (à l'affichage de son menu par exemple). Cela n'en est pas une obligation, et globalement l'OS au dessus est responsable de maintenir l'heure réelle sous-jacente (après tout, c'est lui qui a accès au NTP et à la configuration de l'utilisateur directement).

Comme on peut s'en douter la plupart de ces cas impliquent un programme complexe et surtout des mise à jour régulière, quel intérêt à faire ce genre de chose au niveau de la carte mère ?

La question est : pourquoi pas ? Est-ce grave si la carte mère pour de l'affichage essaye d'afficher une donnée intéressante même si ça peut être faux dans quelques cas ?

Tu vas reprocher à des constructeurs de proposer l'affichage de leur interface UEFI en chinois mais pas en français car tant que toutes les langues ne seront pas dispo ce ne sera pas parfait ? (cas d'une carte mère chez moi, anglais ou mandarin). Je trouve vraiment que tu t'emportes pour pas grand chose dans ce cas-ci.

Et l'UEFI a au moins unifié la politique de manière universelle (car à priori d'autres architectures que l'x86 vont reprendre la spec). Et quelque soit l'OS. Avec les BIOS d’antan, c'était un peu la loterie, suffit de constater les bogues de l'heure quand tu passais de Windows à Linux en dualboot…

Tant qu'on y est pourquoi pas y mettre un OS ? au wait

Quel est le problème ?

Le matériel est devenu un centre de technologie très complexe. Le processeur Intel / AMD / IBM / ARM / autre n'est plus maître à 100% de la machine. Il est guidé par des dizaines de processeurs ou microcontrôleurs avec leur propres logiciels voire mini-OS dedans. Et je ne parle même pas des cartes graphiques qui sont presque des ordinateurs complets à eux seuls. Il est naïf de croire que tu vas retrouver le contrôle de l'ensemble avec ton Linux logé dans le disque dur.

Mais cela a aussi un avantage, comme le processeur principal ne gère pas cela lui même, Linux n'a pas à le faire non plus, et avec la quantité astronomique de combinaison possible, c'est une bonne chose pour la portabilité de nos systèmes et leur fiabilité.

En clair un petit malin peut recuperer l'ensemble de tes donnees si il le souhaite grace a cette magnifique technologie qu'est UEFI.

Tout à fait, de même s'il a inséré une porte dérobée dans ton processeur, le firmware de ton espace de stockage ou le noyau de ton OS.

L'UEFI est un composant parmi d'autres qui a de grandes possibilités sur ta machine, mais heureusement son accès n'est pas aisé, généralisable à grand échelle (l'UEFI d'un constructeur n'est pas compatible avec un autre en terme de code et d'initialisation, seule l'API l'est). Et ce n'est pas le seul dans ce cas.

Le role d'un BIOS c'est juste d'initialiser le hardware et de s'effacer lorsqu'un O/S demarre

C'est un point de vue, mais qui globalement ne colle pas à la réalité.
Même avec l'UEFI, si tu dialoguais directement avec le BIOS tu pouvais jouer à faire des trucs rigolo. Le BIOS sur x86 ne s'est jamais totalement effacé devant l'OS en fait.

Et c'est d'ailleurs un intérêt du BIOS que de fournir une petite abstraction de la machine en dessous pour aider le noyau dans cette tâche. N'oublions pas que c'est en partie cela qui fait que l'ARM est une plaie à gérer car la l'initialisation et la découverte du matériel doit se faire à la main.

C'est secure serieusement ?

Il faut faire attention à distinguer un standard sécurisé et son implémentation qui peut ne pas l'être.

Ce qui soit dis en passant n'est pas un problème. Pourquoi l'UEFI de la carte mère devrait être incapable d'afficher l'heure réelle de chez moi quand j'y vais dedans ? D'autant que ce n'est pas si compliqué avec un OS qui supervise cela au dessus de lui.

Alors là je me demande : le BIOS gère donc tous les fuseaux horaires et changements d'heure !!?? mais pourquoi faire ? C'est pas plutôt à l'OS de gérer ça ? … soit j'ai mal compris : l'UEFI ne calcule pas lui même les changements d'heure mais dispose juste d'un champ "timezone" et d'un champ "DST rules" qui permet à l'OS de le faire ;

C'est ça, en gros l'UEFI permet aux différents OS de gérer l'heure matérielle de la machine proprement de manière univoque.

Cela évite les soucis du passé où Windows et Linux n'interprétait pas le BIOS de la même façon à ce sujet, donnant des heures différentes selon l'OS que tu employait si tu passais de l'un à l'autre.

Je vais déjà essayer d'installer visual code studio sous mon ubuntu.

Visual Code Studio n'est de souvenir qu'un éditeur de texte. Cela ne te sera d'aucune aide pour le faire fonctionner sous Linux.
Cependant le code est en C# (et non en C), tu devrais regarder du côté de mono (ou autre outil .NET pour Linux) pour voir s'il n'est pas possible de le faire tourner sous Linux facilement.

C'est incomplet.

En effet ta Debian n'a pas tous les derniers correctifs concernant le noyau pour ces failles. Mais il en a probablement une partie.

En fait la commande citée repose sur un correctif arrivé plus tard pour décrire en détail ce qui est appliqué ou pas. Mais certains correctifs existaient avant. Mais pas tous.

De plus comme tu n'as pas la dernière version du noyau, tu devras attendre l'application de ces correctifs par Debian ou d'autres développeurs assurant la maintenance du noyau que tu utilises. Cela prend un peu de temps, d'autant que Debian n'est pas du genre à avoir une politique de mise à jour rapide.

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.

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

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.

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.

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

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.

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.

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.

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.

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.

Le but de ces taxes n'est pas de financer l'État mais de financer des programmes de sensibilisation, de dépistages, de soins (ou dans le cas de l'énergie, la transition énergétique et financer la recherche du domaine).

Rien n'empêche d'ailleurs pour l'État de changer sa fiscalité si jamais la transition entraîne une baisse budgétaire insoutenable.

De sûr, les fumeurs payent moins en taxe que le coût que le tabac engendre à la sécurité sociale. Pour l'alcool, n'ayant jamais étudié la question je ne me prononcerais pas.

Je pense en tout cas qu'il est plus pertinent de taxer des produits mauvais pour la santé ou de subventionner / réduire la TVA / autres pour pratiquer une activité sportive que de moduler la prime d'assurance.

Je pense que cette méthode permet d'être plus efficace pour changer de comportements (car tu sanctionnes financièrement la mauvaise habitude directement) et évite que ceux qui auront besoin d'une assurance finalement n'y souscrivent pas car trop cher.

Notons que Firefox intègre deux listes de Disconnect pour sa protection automatique contre le pistage (que l'on peut étendre bien entendu).

Cela est disponible dans la partie Sécurité et vie privée des préférences de Firefox. Depuis les extensions du type Disconnect me semblent superflues aussi.

Même en vivant au fond de l’Amazonie sans internet tu ne peux plus éviter le tracking.
Le tracking ne se limite pas aux fichiers logs des serveurs que tu visites, il y a aussi toutes la partie automate et IOT (exemple les bancontacts *1), les trucs communautaires (OpenStreetMap, Pokemon Go), les drones et satellites (petit exemple avec les drones chinois), se que les gens postent à ton propos sur les réseaux sociaux et ce même si tu leur interdis.

*1 la ville de Liège se sert du tracking des payements pour créer des maps des déplacements des consommateurs à l'intérieur de la ville

La question est : est-ce possible et souhaitable qu'aucune activité ne puisse générer du tracking ? Par exemple il semble évident dans les télécoms et le système bancaire qu'on puisse identifier qui a fait quoi et quand. Car techniquement tu n'as pas le choix (après tu peux supprimer ces données au fur et à mesure, bien entendu, mais en soit le tracking est techniquement obligatoire).

Puis le tracking a de bons côtés, la question est de son usage, de la granularité et éventuellement de l'anonymisation. Par exemple, en Belgique comme tu le soulignes, Orange a aussi fourni au gouvernement des informations sur les déplacements de ses utilisateurs de zone à zone pour un évènement donné (donc granularité au niveau de la ville, pas du bâtiment).

Ces données sont essentielles pour comprendre les flux de la population au sein des villes et des pays. Pour notamment mieux anticiper certains évènements qui rameutent du monde (ce qui demande de l'organisation) mais aussi pour dimensionner le service public (par exemple les transports aux communs) aux besoins réels. Si par exemple on observe un flux particulier le samedi en terme de trajets, peut être que la ville peut décider d'y ouvrir une ligne de bus ou autre. Sans le tracking tu seras bien moins précis et faudra faire des expérimentations coûteuses et délicates pour vérifier.

Bref, le tracking de la population a aussi des effets positifs. Mais le tout doit être fait dans un cadre qui limite les dérives possibles. De toute façon si tu ne veux pas être tracké, je pense que la meilleure solution est de se passer des solutions techniques qui en dépendent.

Ni observer un entrepôt pour savoir ce qui y est stocké, et comment y accéder de nuit sans déclencher d'alarme.

Je pense que si tu traines trop longtemps auprès d'un lieu où tu n'es pas convié pour observer la sécurité du coin, les propriétaires (que ce soit des propriétaires d'une entreprises ou d'une maison particulière) vont appeler les flics pour comportement douteux et ils vont t'interroger sur tes motivations.

Je ne vois pas l'intérêt de scanner un site quelconque sans y avoir été convié. Soit tu veux faire quelque chose d'illégal avec, soit tu veux les aider. Mais si tu veux les aider il y a un moyen simple : tu les contactes avant. Car de toute façon si tu le fais dans leur dos et qu'ils s'en aperçoivent, ils pourraient avoir peur et t'attaquer en représailles. Ils peuvent aussi ignorer tes résultats car ils ne t'auraient rien demandés ce qui t'aurait fait perdre du temps.