Misc a écrit 5882 commentaires

Faut dire que la dernière fois qu'il s'est occupé de la restauration, ça s'est pas super bien fini.

Et c'est pour ça qu'il y a aussi Pâques juste après, car Jésus est revenu après nous avoir tous sauvé ?

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.

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.

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.

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:

 $ ls /var/lib/dpkg/info/*.post* | wc -l
716

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.

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.

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.

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.

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 build, mais soit n'ont pas le bon état d'esprit soit ont une forme d'ego pensent que leur projet a une spécificité.

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

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

https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b

semble donner plus d'info

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

Tu veux parler de sssd ?

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

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.

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

https://tukaani.org/xz-backdoor/

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.

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.

J'ai vu qu'il y a un .o dispo dans le mail d'origine: https://www.openwall.com/lists/oss-security/2024/03/29/4 et le mail dit: "Florian Weimer first extracted the injected code in isolation, also attached, liblzma_la-crc64-fast.o, I had only looked at the whole binary. Thanks!"

La backdoor était sous la forme de code binaire caché dans les données de test, donc il n'y a que le .o pour le moment. Je ne doute pas que dans quelque jours, quelqu'un va coller le dump en assembleur avec une analyse. Il y a 87 ko de code compilé, avec du code existant, donc ça doit pas être non plus trop gros.

Il y a une version dans le thread avec plus de symboles, ça peut aider pour le débogage.

Thread sur Fedora:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IJRW6X34BBJQLAQ64G53S7XPRU35U7KN/

pour savoir si sshd dépend de liblzma, et savoir si la vulnérabilité est potentiellement présente.

Modulo le fait que pam charge à la volée ses modules (mais aucun ne semble dépendre de liblzma sur ma machine). Et que libsystemd aussi depuis 1 mois, comme l'a souligné Lennart P sur HN à un moment.

En effet, j'avais complètement zappé ce point (alors que je l'ai lu). Ça fait tombé mon analyse à l'eau :(

Quand je lit les commentaires sur la sophistication de la backdoor, et le fait que l'attaquant a visé spécifiquement les paquets de distros, ainsi que d'autres libs, je pense que la cible n'était pas sshd.

Je pense que l'idée était de rajouter une backdoor pour signer des paquets rpms/debian avec une clé arbitraire. Ça expliquerait pourquoi il y a eu un souci avec sshd, car l'attaquant n'avait pas du tester ce cas de figure (vu que la dépendance est transitive via systemd, et ça ne semble être actif que via des options bien spécifiques).

mais liblzma est utilisé aussi par librpm et par dpkg. Le fait de modifier des trucs du coté des fonctions RSA me fait penser aux signatures des paquets, et ça me semble plus probable, ça laisse moins de trace.

https://news.ycombinator.com/item?id=39865810

https://lobste.rs/s/uihyvs/backdoor_upstream_xz_liblzma_leading_ssh

https://lwn.net/Articles/967180/

Il y a eu des discussions ici et ici, mais je pense que c'est plus parce que Madelyn Olson s'est focalisé sur trouver un endroit ou mettre le projet (eg, la LF) pour faire collaborer les industriels (eg, AWS, Alibaba, Google, etc) alors que Drew a juste dit "fuck it, qui m'aime me suive" et il est parti sur Codeberg, un point que je trouve assez discutable.

Je suppose qu'implicitement, il y a aussi le coté un peu rugeux du dit Drew (je sais pas ce qu'il a fait, mais j'ai eu plusieurs échos).

Comme le souligne Madelyn, la LGPL ne change rien pour les boites qui proposent du Redis en tant que service hébergé, donc je trouve ça assez curieux de dire que ça ne leur convient pas.

Oui, je dit parfois que le logiciel libre est la par le surplus de productivité de certaines personnes. On a du code libre parce qu'il y a des bénévoles, on a du code libre parce qu'on a des gens payés qui sont plus productif en reprenant du code libre qu'en codant de 0 (tout les softs écrit par des admins de facs, surtout au début, mais aussi sans doute l'embarqué d'une manière général). Et la, ton exemple rentre aussi la dedans, on a du code libre par les hyperscaleurs parce qu'ils ont du coder ça de toute façon, donc autant le libérer.

Mouais, ensuite, si tu regardes la timeline de tout ça, c'est plus compliqué.

Redis le projet (2009) est plus ancien que Redis l'entreprise (ex Redis-labs) qui a été crée en 2011 sous le nom Garantia Data par 2 entrepreneurs, aucun n'étant fondateur de Redis le projet. Le créateur n'a rejoint Redis l'entreprise qu'en 2015 (après avoir quitté pivotal, si je me souviens bien), et il a quitté la boite en 2020.

AWS propose AWS Elasticache depuis… 2011 avec un support de Redis depuis septembre 2013 (et Memcached avant). Redis la boite/Redislabs/Garantia Data ont sorti leur offre plus tôt (février 2013), mais c'était pas les seuls sur le marché, vu que Myredis, qu'ils ont achetés en octobre 2013, proposait déjà le même service en 2012 en beta, et en février 2013 en GA ( cf la date de https://news.ycombinator.com/item?id=5294122 ). Donc à quelques mois prêt, tout le monde a eu la même idée (vu que Garantia Data avait aussi une offre de SaaS pour Memcached, soit la même chose qu'AWS, quelques temps après AWS).

Je veux bien dire du mal d'Amazon, mais quand Garantia Data a décidé de se renommer en Redislabs puis en Redis puis de prendre du capital risque 7 ou 8 fois d'affilés pour devenir éditeur, ils savaient qu'AWS était la depuis le début, et ils n'avaient pas trop l'excuse d'avoir fondé le projet eux même vu qu'ils ont fondé la boite puis décidé de devenir le sponsor principal pour rajouter des plugins pour leur business modéle de l'époque (aka, la marketplace) .

La boite aurait parfaitement pu être comme la plupart des boites qui font du support sur Postgresql et du consulting, mais c'est pas le choix qui a été fait, sans doute parce qu'à un moment, faut avoir du ROI.

Redis la boite a choisi de faire de l'édition son gagne pain, sans doute parce que ça rapporte plus que les autres types de gagne pain. Et quand ils ont fait ce choix, AWS et co était déjà la. Donc bon, ils ont tentés de jouer gros, et visiblement, ils n'ont pas gagner.

Même sans parler des mises à jours de version, je peux donner des exemples (et même des exemples qui n'impliquent pas de dire qu'une femme plus âgée est moins compétente que la moyenne).

Par exemple, à l'époque ou je faisait le support sur le terrain pour des commerciaux, j'avais régulièrement des gens qui venaient avec un laptop sous RHEL incapable de booter. J'ai fini par diagnostiquer ça comme étant le symptôme d'un reboot pendant les mises à jours.

J'ai constaté que mes collègues du département Vente avait la bonne habitude de lancer les mises à jour en tache de fond, puis d'oublier l’existence des dites mises à jour en cours et soit de tomber soit en panne de courant, soit d'éteindre le PC. Avec assez de monde et assez de mises à jours, ça finit par arriver.

Normalement, RPM est assez solide pour survivre à ça dans le sens ou sur une RHEL, ça devrait pas rendre la machine indémarrable. Il faut parfois repasser en root et faire du nettoyage pour finir la transaction, etc, donc passer du temps, mais c'est pas bloquant.

Par contre, il y a un rpm qui a un souci avec ça, c'est le kernel, car le kernel sur RHEL, il a 2 scripts de post installation. Un script en %post et un en %posttrans. Quand tu installes le rpm, il lance le script en %post, qui va modifier la config grub, et rajouter le nouveau kernel et initrd. Quand tu as fini d'installer tout les autres paquets, le script %posttrans (pour post transaction, la transaction étant l'installation de tout les paquets comme dans un SGBD) va lancer la création de l'initrd. C'est fait après l'installation pour être sur d'avoir tout les fichiers à jour après la mise à jour. Par exemple, si il y a une mise à jour de bash et du kernel, tu veux avoir le dernier bash dans l'initrd, pour éviter les bugs ou les soucis de sécu corrigé par une mise à jour de bash.

Sauf que, si tu coupes la mise à jour en cours, tu te retrouves avec la config de grub modifié, mais pas l'initrd correspondant, et donc au reboot, le choix de kernel de grub est non fonctionnel vu qu'il pointe vers un initrd qui n'est pas encore sur le disque, donc ça coince.

Alors il y a plusieurs correctifs possibles. Mettre l'ajout du kernel dans la config grub dans le scipt %posttrans après la création de l'initrd. Faire en sorte que grub soit moins con et vérifie la présence des fichiers et bascule sur un choix par défaut. Faire l'initrd 2 fois, dans le %post et le %posttrans. Ou utiliser ostree.

Car en effet, tout le probléme disparaît avec ce genre de systèmes. Les mises à jours sont téléchargés en entier avant d'être appliquées d'un coup au reboot. Si tu coupes le téléchargement, rien de dramatique se passe et ça peut reprendre plus tard. Si ça ne démarres pas, tu peux automatiquement revenir en arrière (en théorie).

Et ça, c'est sur une RHEL, ou les questions de mises à jours majeurs de rpms ne se posent pas trop, en tout cas pas sur la durée d'usage des portables comparée à la durée de vie de la distro.

Oui, mais du coup, pipenv et co, ça marche sans silverblue, non ?

Du coup, je pige pas quel est l'apport pour ton workflow, à part d'être sur que tu installes rien en root par erreur.