benoar a écrit 4229 commentaires

Un Thinkpad parce qu'il n'y a que ça de vrai, série « T » pour du pro en taille raisonnable (14") (sinon « X » pour du réduit, mais va disparaître), et maintenant ils font de l'AMD donc T495 :
https://www.lenovo.com/fr/fr/laptops/thinkpad/t-series/T495/p/22TP2TTT495

La batterie n'est pas « amovible » au sens classique, mais se remplace si tu sais enlever quelques vis. Pour les deux disques, il y a potentiellement deux M.2, mais le second est un court donc ça va être galère. Et par contre, Windows obligatoire…

Vous avez tous les deux raison : je pense que NeoX parle de GPT, et toi d'UEFI :-)

Un doute m'est venu juste après avoir posté ce commentaire : existerait-il un module gitlab à weboob, afin de boucler la boucle ? Apparemment non. Ça aurait été méta-drôle, même si j'aurais plutôt ri méta-jaune.

J'arrive après la bataille, mais je voulais lancer un petit troll relatif au cœur du projet : on ma demandé de relancer un patch que j'avais proposé sur la ML (assez morte, par ailleurs) par le gitlab de weboob, sur https://git.weboob.org/
Et là je me suis dit « Comment ? Les devs de weboob osent demander de passer par le web afin de contribuer à ”web out of browser” ? ». Du coup ça m'a fait une excuse pourrie pour ne pas rebaser le patch et reporter le boulot à plus tard /o\

Intéressant comme méthode, mais ta création de partition en masse m'a tout de suite fait penser à plutôt utiliser le device mapper, cf man dmsetup(8).

Tu laisses ton disque non-partitionné, et tu crées un fichier qui contient la « table » des morceaux de disque que tu veux agréger dans un nouveau device, selon la syntaxe indiquée dans le manuel :

0 900000 linear /dev/sda 4100000
0 900000 linear /dev/sda 5100000
…

Ensuite tu crées le device :

dmsetup create disque_aggrege --table ma_table.txt
Sache que le Device Mapper est le mécanisme « bas-niveau » utilisé par lvm et dmraid (entre autres), c'est donc du « classique » mais que tu fais ici à la mano ! Par contre j'ai un petit doute sur l'imbrication de device (vu que tu va créer des mapping avec LVM sur ce device qui est déjà un aggrégat de mapping linéaire), mais je pense que ça passe normalement.

Si tu veux voir comment ça fait avec tes devices LVM actuels, histoire de comprendre :

dmsetup ls
dmsetup table mon_device


Ah, je ne savais pas pour les extensions.

Par contre, ton VirtualGL c'est autre chose : c'est utiliser l'accélération du client X11 pour envoyer des frames déjà rendues sur le client au serveur X11. Après, l'argument qu'ils avancent de la non-efficacité de faire de l'OpenGL à distance est peut-être vrai, mais du coup s'applique (de ce que je comprends) également à waypipe avec accélération 3D.

genre la 3D que propose simplement waypipe avec DMABUF.

X11 peut forwarder l'OpenGL sur le réseau depuis 20 ans à peu près…

Et en plus avec des bières, dans des bouteilles en verre ! C'est « hallucinant » d'une certaine manière, mais tellement humain en vrai.

Je ne suis pas sûr qu'on se soit bien compris, mais :

Pas évident de devoir choisir entre tourner à 30% de perfs ou tripler la facture d'hébergement.

Si tu parles bien d'utiliser sa propre infrastructure qu'on maîtrise pour le triplage de la facture, oui effectivement ça n'est pas un choix facile. On ne peut malheureusement pas tout avoir.

Bref utiliser Debian avec des packages traçables n'évite absolument pas le problème. Ça mitige un peu dans le sens ou effectivement tu n’exécutes pas un code tiers qui a une intention malicieuse à la base - mais pour autant ça ne bloque pas une attaque via des logiciels établis.

Alors tout ton post parle de recompilation alors que ça n'est pas du tout ce que je promeus ! Au contraire, utiliser des programmes libres utilisant toutes les instructions que tu veux, déjà compilés par ta distro, puisque (dans mon hypothèse) tu n'as pas à te soucier de problèmes de programmes qui ne seraient pas de confiance puisque tu n'utilises que des programmes libres de confiance (ceux de Debian).

Après, une attaque « via des logiciels établis » est toujours possible, mais on commence encore une fois selon moi à entrer dans des probabilités tellement basses que la question du compromis tiens toujours : je préfère me concentrer sur d'autres facteurs (avoir des machines bien à jour, bien configurées) que de psychoter sur un problème avec une probabilité d'arriver minimale.

Si tu as un master 2 ou un DESS, ta formation est aussi sérieuse et complète que celle d'un ingénieur

Peut-être pour certaines écoles d'ingé, plutôt privées comme tu l'indiques, mais j'ai « comparé » avec des gens que je connais bien issus d'école publiques renommées, et pour moi il y a quand même quelque-chose « en plus » avec celles-ci (INSA en l'occurence). Ou alors c'était ma fac qui n'était pas géniale…

Bon après il y a également l'effet réseau professionnel qui te permet « automatiquement » d'avoir des postes mieux après de bonnes écoles d'ingé, mais ça ça n'est pas très reluisant.

Le moindre pilote client de base de données ou wrapper Vagrant (et on va pas parler de Docker, KVM, XEN et co.) peuvent potentiellement permettre un nouveau vecteur d'attaque. Il doit pas y avoir grand monde avec le temps, les compétences et la volonté de "maitriser son informatique" à ce point.

À une époque, on ne filait pas un gros blob binaire construit spécifiquement pour une utilisation aux gens : on précisait des dépendances « standard », qui pouvaient même être intégrées à un système de gestion de paquet, on avait des soft qui s'adaptaient à des environnement un peu hétérogènes histoire de pouvoir tourner sur les environnements différents existant chez chacun, et on utilisait des formats et protocoles standards.

Aujourd'hui, on fait des images toutes prêtes qui incluent toutes les dépendances figées et inauditables, intégrées dans des systèmes ni signés et peu reproductibles, avec des softs qui ne tolèrent aucune souplesse et sont dans la monoculture, en utilisant des API propres à chaque appli et sans format standard définit.

L'industrie a bien changé en dix ans, oui. Je ne dis pas que le premier modèle n'a pas de désavantages (déploiement plus complexe, moindre rapidité d'évolution radicale, scalabilité plus manuelle), mais au moins niveau maîtrise, fiabilité et insensibilité à ce genre de bug on était beaucoup mieux lotis. Alors déplorer aujourd'hui que « ça n'est pas possible, ma bonne dame », c'est oublier qu'on a troqué des choses qui existaient et qui marchaient très bien contre des petits avantages de praticité qui — en rétrospective — ne valent peut-être pas tant que ça le coup. Même si chacun aura un avis différent sur le côté duquel penche le compromis pour lui.

Perso j'ai choisi Debian, ça n'est pas un choix irréaliste : c'est reproductible, signé, auditable, standard, etc. Je ne vois pas comment on peut écarter un tel bon système en disant qu'il n'existe pas d'alternative au tout « j'exécute n'importe quel binaire » d'aujourd'hui.

Il y a un exploit Meltdown/Spectre qui permet de récupérer l’intégralité de la RAM, en quelques minutes, sans aucun log.

Ça a été montré pour un cas spécifique, mais perso je n'ai pas pu le reproduire, et d'autres personnes me l'ont également confirmé. C'était au début, ça s'est peut-être amélioré depuis, mais on reste sur des méthodes probabilistes qui dépendent d'un alignement de bonnes étoiles (même si oui, ça peut arriver).

Bah vas-y, donne nous tes astuces et bonnes pratiques, on attend que ça.

Ça se fait pas en un commentaire, et je ne suis pas un méga-spécialiste qui pourrait se permettre de lister ça sereinement. Ce que je veux dire, c'est que la publicité faite sur ces failles occulte un tas d'autres choses qui sont plus importantes, c'est tout.

tu fais tourner tous tes processus en root.

Pas ceux des utilisateurs déjà, puisque l'utilisation des droits est déjà une barrière pour les problèmes humains, qui par définition ne sont pas contrôlable par un admin comme les programmes qui tournent sur sa machine.

Pour les démons, effectivement on met une protection en plus à priori « pas nécessaire » que je trouve déloyal de comparer à cette faille-ci : je pense qu'il y a beaucoup plus de probabilité qu'arrive une RCE qui ne sera pas exploitable pour éscalader les droits que quelqu'un vienne te faire un cacheout sur des secrets spécifiques pour arriver à ses fins. Faire tourner des démons avec des droits distincts, c'est relativement simple, n'a pas d'impact de perf, et te protège de beaucoup de choses. Ici, c'est chiant à mettre en place, pour un gain vraiment très faible. C'est la différence que je fait.

Globalement, avec ce genre de faille, ça veut dire qu'à la moindre RCE, tu bypass les protections du système […] et qui installe un malware dans le bios/uefi

La probabilité que ça arrive est à mon avis assez faible. Mais bon, c'est juste mon avis.

En fait, on ne fait aucune pub pour toutes les bonnes pratiques autres qui sont beaucoup plus logiques et simples à appliquer, et on passe son temps à parler des ces trucs hyper techniques qui ont des probabilité de fonctionner tellement faible que ça en est ridicule. Ça fait parler de Intel, et du bad buzz c'est quand même du buzz, et on donne une attention complètement disproportionnée à ce genre de problème. Ça entraînera forcément une négligence sur d'autres aspects qui auraient pu être beaucoup plus constructifs.

Tu as l'air de dire que tout le monde doit maîtriser à mort son infra.

J'aimerais, mais je sais bien que ça n'est pas possible. Et à ce moment-là, comme le dit kowalsky, tu as bien d'autres problèmes plus prioritaires à te soucier que ces failles.

se connecter sur une de tes machines via un compte non privilégié, il peut utiliser cette faille --> ta super maîtrise est par terre.

Je suis d'accord qu'il faut avoir plusieurs niveaux de protection, mais franchement il y aura à mon avis plus simple que cette faille pour arriver à tes fins dans ce cas-là. On fait tout un foin sur cette histoire, alors que plein de gens font tourner des tas de containers pas à jours avec aucun suivi de CVE. Tu veux essayer de « mitiger » après avec ta super protection anti-Cacheout ? Ton ordre des priorités est vraiment étrange, selon moi.

Encore une fois, il faut voir dans quel contexte c'est exploitable : pour des gens qui font tourner du code malveillant utilisant les instructions TSX. Qui fait ça ? Ceux qui installent du code venu de n'importe où, sans vérifier. Vous étonnez-vous qu'après il y ait des problèmes ?

Ça affecte aussi ceux qui sont collocalisés sur des hyperviseurs avec des VMs adjacentes malveillantes : déjà, les chercheurs qui ont trouvé la faille indiquent avoir déjà prévenu les fournisseurs de cloud (ils ne précisent pas lesquels, comme si c'était évident qu'il n'y en ait que quelques gros…), et puis quand vous faites tourner votre code sur la machine de quelqu'un d'autre, vous étonnez-vous que vos données puissent éventuellement fuiter ?

Pour une fois, je ne vais pas râler sur l'utilisation à outrance de codes inconnus dans un browser par Javascript puisque cette faille-ci nécessite l'utilisation d'instructions TSX, qui ne sont pas accessibles en JS.

Bref, cette attaque est encore une fois très spécifique, et n'affecteront jamais des personnes qui utilisent uniquement du logiciel libre et maîtrisent leur informatique. Si vous utilisez du logiciel privateur ou faites tourner votre code sur la machine de quelqu'un d'autre, il y a bien d'autres « problèmes de sécurité » à vous soucier avant ce genre de faille ! Cf. ce que j'avais déjà dit ici.

Alors après c'est techniquement très intéressant à lire, merci patrick_g ! Et je ne suis pas un pro-Intel du tout, bien au contraire, je trouve que c'est « bien fait » pour eux qui ont toujours utilisé des méthodes très limite pour imposer leur mainmise sur l'industrie. Mais franchement, l'impact réel du truc… Ah si, ça permettra d'avoir des CPU Intel puissants pas cher d'occasion pour ceux qui n'utilisent que du libre !

Moi. Master universitaire, même si j'ai essayé d'entrer avant en école d'ingé mais n'ai jamais réussi. Comme Sébastien, tu as toujours légèrement l'impression d'être un usurpateur, mais avec l'expérience je me dis que « je compense ». Mais c'est vrai que la validation d'acquis m'avait toujours titillé : cependant, vu le long parcours (très bien rapporté !) il faut vraiment le vouloir…

OK, merci, j'avais oublié ça également.

Ah oui, parce que les script inline sont exécutés d'abord (de mémoire), et ainsi il place le script sourcé avant tous les autres ? Pourquoi pas, quand tu ne maîtrise pas totalement la manière dont ça va être templaté après. Mais quand même, qu'est-ce que c'est moche…

Merci.

Pourquoi ce ton agressif et condescendant ?

J'avoue, c'est un peu perso. Voir toutes les habituelles tares du JS plus ton nom, je me suis lancé. C'est con je sais.

Tu te trompes dans ton analyse, j'ai commencé par le JavaScript comme je l'indique explicitement dans mon journal. Tu manque donc d'humilité et insulte à la légère.

Effectivement, j'avais pourtant compris ça en premier, puis en rédigeant un peu vite et en mode « clash », j'ai inversé le sens.

De plus, la solution que je présente pour ce problème s'affranchit du besoin de connaître la langue du mois à convertir. Ça me semble inédit et digne d'intérêt.

Effectivement, je n'avais pas vu ça. Même si c'est intéressant de poster également les limites après comme tu l'as fait (langues différentes ayant les même mots pour des mois différents).

Pour être plus clair, pourquoi n'écrit-t-on pas directement :

<script src="//gc.zgo.at/count.js" async="1">


Pour ma gouverne, est-ce quelqu'un peut m'expliquer l'intérêt pour un script de créer un autre script qu'il va exécuter ? Je suppose que ça a à voir avec l'ordre de chargement de la page ou autre connerie comme ça, mais ne connaissant pas toutes les subtilités du JS et des navigateurs modernes… Sans parler de la définition de fonction anonyme pour l'exécuter instantanément, j'ai oublié également son utilité mais j'ai cru comprendre que cette construction elle aussi idiomatique était soit-disant « logique »… Quelqu'un qui débarquerait sans connaître le web trouverait cette triple indirection complètement folle.

Tu n'as toujours pas compris… ou alors il y a quelque-chose que je ne saisis pas, mais vu que tu as ajouté zéro précision sur ton cas…

Tu me dis, si je comprends bien, que tu as un lien avec une très grande latence, et que tu souhaiterais que tes extrémités discutent avec des paquets de taille adaptée à la taille réduite du tunnel. Oui ? Le MSS est un hack qui modifie en vol les SYN TCP afin que les extrémités s'adaptent à cette taille. Ça marche en TCP seulement.

Moi au début je croyais que tu parlais uniquement de problème de passage tout court de paquet, pas de problème de perf. Faire fragmenter le routeur qui gère le VPN est la manière « classique » de régler le problème de non-passage de paquet, modulo qu'il faille vérifier que l'ICMP est correctement routé des deux côtés à l'extérieur du tunnel. Si tu voulais en plus des bonne perfs, tu pourrais te baser sur les réponses ICMP pour dire que les paquets sont trop gros. C'est inclus de base en IPv6, pour v4 le routeur fait par défaut la fragmentation, mais tu pourrais rajouter une règle pour qu'il renvoie à la place à « fragmentation needed ». Et là ça marcherait pour tous les protocoles.

Après si ton cas d'utilisation principal c'est du Web-only et que tu t'en fous du reste…

Sans déconner, réinventer le parsing de date ? Je croyais qu'on arrêtait après l'université…

La structure de donnée est réutilisable pour d'autres langages de programmation. J'ai commencé avec une version Python qui a fonctionné directement pour 49 langues (je n'ai pas encore compris ce qui coince pour les autres).

Il se trouve qu'il existe déjà un ensemble de traductions, qui est justement utilisé pour faire la traduction dans le sens index -> représentation linguistique. Ça s'appelle des locales, c'est cent fois plus standard que ta structure, et il existe même une fonction POSIX pour ça : strptime(3).

Ah bien sûr, tu as commencé par du Python sans lire la doc, puis sur ce langage moisi qu'est Javascript, et tu as ensuite amené ta perversion vers le reste de nos beaux systèmes… NIH, quand tu nous tiens.

Pour l'exemple, en Python :

import locale
import datetime

locale.setlocale(locale.LC_ALL,('fr_FR','UTF-8'))
datetime.datetime.strptime("août","%B").month

Et je n'ai pas compté le nombre de langues dans lequel c'est traduit pour enlarger ma réputation, mais je m'en fous, puisque je n'aime pas passer mon temps à merger des pulls request de choses qui ont déjà été bien mieux faites par d'autres avant moi.

Au lieu de fumer des trucs pas nets qui te font aimer des discours tarés de gourous du JS, commence par RTFM !

Alors je suis allé voir la doc sur ce nouveau type de chaîne littérale :
https://docs.python.org/3/reference/lexical_analysis.html#formatted-string-literals

En fait, ce sont des chaînes qui sont évaluées automatiquement, au lieu d'avoir à passer par le classique .format(). Et c'est là qu'on commence à entrevoir la faille avec tes doubles accolades qui me laissaient perplexes au début…

Mais franchement, ce genre de feature « magique », ça sent vraiment pas bon et je n'aime pas, ça n'est pas quelque-chose que j'utiliserai dans mon code.

Sur OpenVPN la réduction de la MTU en tap (Layer 3) s'accompagne d'une réécriture de la MSS, mais pas sur wireguard (peu être un bug de ce dernier).

Les deux ne sont pas forcément liées : OpenVPN a un comportement « tout en un » pour soit-disant faciliter la vie, mais il n'y a aucune raison de toujours ajouter du fix de MSS, qui est quand même une verrue assez immonde ! Diminuer la MTU devrait très bien permettre au routeur ayant l'interface VPN de fragmenter comme il faut, pour les paquets qui lui arrivent à forwarder dans le tunnel. Après, il faut faire gaffe que ça marche également dans l'autre sens, à l'autre bout. Bref, sans plus de détail sur ton setup et la description exacte de tes problèmes, pas facile d'être sûr du problème.