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.
L'article lié mentionne que le backdoor se déclenche seulement si argv[0] (le nom du programme en cours d'exécution) est "/usr/sbin/sshd", et que l'exploit permet de détourner les clés RSA utilisées pour une connexion SSH. Difficile de penser que ça cible autre chose que sshd?
Même pour les « edge distributions » potentiellement affectées, il faudrait être presque en avance sur son temps. Sur Gentoo la dernière version stable de xzutils était la 5.4.6-r1, qui vient d'être remplacée par la 5.4.2 au cas où :
« Newer releases were signed by a potentially compromised upstream maintainer. There is no evidence that these releases contain malicious code, but masked out of an abundance of caution. »
Mais de toutes façons, contrairement à Debian, openssh n'était pas patché pour l'employer (cf. article du lien). Donc ce risque était probablement nul.
Au passage, il me semble que le script de détection de la vulnérabilité ait un bogue : chez moi il ne retourne aucun message…
De toutes façons, il suffit d'extraire la commande
ldd $(which sshd)
pour savoir si sshd dépend de liblzma, et savoir si la vulnérabilité est potentiellement présente.
Reste un côté sérieusement inquiétant : si l'attaque s'est trouvée détectée de ce côté-là (un peu par chance si je comprends bien, pour une petite demi seconde…), rien n'empêche que d'autres tentatives aient (eu) plus de succès, et ne trouvent leur chemin jusque dans des distributions publiées. J'imagine que ce genre de scenario est appelé à se multiplier avec les relations internationales de notre époque.
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.
Nulle part je ne trouve une analyse du code de la backdoor?
Alors on, ça cible les fonctions RSA de sshd donc on se doute que la backdoor permet un bypass de l'authentification, mais est-ce que quelqu'un a extrait le code et fait une analyse complète ?
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.
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.
Alors. Avoir le dump assembleur, c'est très simple. On fait un coup de objdump -d et hop.
Ou pas.
Ca démarre pas très bien :(
liblzma_la_crc64_fast_o: format de fichier elf64-x86-64
Déassemblage de la section .text.x86_codd :
0000000000000000 <.Lx86_code.part.0>:
0: f3 0f 1e fa endbr64
4: 41 54 push %r12
6: b9 02 00 00 00 mov $0x2,%ecx
b: 49 89 f4 mov %rsi,%r12
e: be 12 00 00 00 mov $0x12,%esi
13: 55 push %rbp
14: 48 89 d5 mov %rdx,%rbp
17: ba 46 00 00 00 mov $0x46,%edx
1c: 53 push %rbx
1d: 48 89 fb mov %rdi,%rbx
20: 31 ff xor %edi,%edi
22: 48 83 ec 20 sub $0x20,%rsp
26: e8 00 00 00 00 call 2b <.Lx86_code.part.0+0x2b>
2b: 85 c0 test %eax,%eax
code à l'adresse 0. Et toutes les fonctions sont comme ça:
Déassemblage de la section .text.lzma_block_buffer_encoda :
0000000000000000 <.Llzma_block_buffer_encode.0>:
0: f3 0f 1e fa endbr64
4: 48 29 fe sub %rdi,%rsi
7: c7 44 24 f8 e2 05 00 movl $0x5e2,-0x8(%rsp)
e: 00
f: 89 d0 mov %edx,%eax
(...)
Déassemblage de la section .text.lzma_raw_coder_memusaga :
0000000000000000 <.text.lzma_raw_coder_memusaga>:
0: 55 push %rbp
1: 49 89 f8 mov %rdi,%r8
(...)
Déassemblage de la section .text.lzma2_encoder_inia :
0000000000000000 <.Llzma2_encoder_init.1>:
0: f3 0f 1e fa endbr64
4: 41 57 push %r15
(vous avez noté que toutes les fonctions ont remplacé leur dernière lettre par un 'a' ?)
Bref. Allons voir du côté des relocations du coup.
$ readelf -rW infected_lib.so
Section de réadressage '.rela.text.x86_codd' à l'adresse de décalage 0xe2e8 contient 7 entrées :
Décalage Info Type Valeurs symbols Noms symboles + Addenda
0000000000000027 0000007900000004 R_X86_64_PLT32 0000000000000000 .Llzma2_decoder_end.1 - 4
000000000000020a 0000001c00000002 R_X86_64_PC32 0000000000000000 .rodata.BRANCH_TABLE0 + 1c
000000000000032f 0000001c00000002 R_X86_64_PC32 0000000000000000 .rodata.BRANCH_TABLE0 - 4
00000000000003ee 0000001b00000002 R_X86_64_PC32 0000000000000000 .rodata.MASK_TO_BIT_NUMBER0 + 5c
0000000000000494 0000001b00000002 R_X86_64_PC32 0000000000000000 .rodata.MASK_TO_BIT_NUMBER0 + 3c
0000000000000515 0000001b00000002 R_X86_64_PC32 0000000000000000 .rodata.MASK_TO_BIT_NUMBER0 + 1c
000000000000053c 0000001b00000002 R_X86_64_PC32 0000000000000000 .rodata.MASK_TO_BIT_NUMBER0 - 4
Section de réadressage '.rela.text.lzma_raw_coder_memusaga' à l'adresse de décalage 0xe390 contient 2 entrées :
Décalage Info Type Valeurs symbols Noms symboles + Addenda
0000000000000016 0000003800000004 R_X86_64_PLT32 0000000000000000 .Llzma_block_buffer_encode.0 - 4
000000000000004a 0000008600000004 R_X86_64_PLT32 0000000000000000 .Lx86_code.part.0 - 4
Section de réadressage '.rela.text.lzma2_encoder_inia' à l'adresse de décalage 0xe3c0 contient 4 entrées :
Décalage Info Type Valeurs symbols Noms symboles + Addenda
0000000000000060 0000000100000002 R_X86_64_PC32 0000000000000000 .text.lzma_raw_coder_memusaga - 4
LOL PTDR! C'est un véritable challenge, là. Juste à comprendre ce que tu reloges ou pas. J'ai jamais vu ça. Du coup, je comprends mieux les gens qui ne donnent pas une analyse. Rien que reconstruire le vrai binaire, c'est un truc de gueudin. Je préfère aller boire un coup et attendre que quelqu'un le fasse, haha
# Annonce chez Red Hat
Posté par Colargol . Évalué à 10.
https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users
[^] # Re: Annonce chez Red Hat
Posté par Okki (site web personnel, Mastodon) . Évalué à 9.
[^] # Re: Annonce chez Red Hat
Posté par Misc (site web personnel) . Évalué à 3.
Thread sur Fedora:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IJRW6X34BBJQLAQ64G53S7XPRU35U7KN/
# Sur HN, LWN et ailleurs
Posté par Misc (site web personnel) . Évalué à 7.
https://news.ycombinator.com/item?id=39865810
https://lobste.rs/s/uihyvs/backdoor_upstream_xz_liblzma_leading_ssh
https://lwn.net/Articles/967180/
# Je pense que sshd n'était pas visé
Posté par Misc (site web personnel) . Évalué à 6.
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.
[^] # Re: Je pense que sshd n'était pas visé
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 29 mars 2024 à 19:59.
L'article lié mentionne que le backdoor se déclenche seulement si
argv[0]
(le nom du programme en cours d'exécution) est "/usr/sbin/sshd", et que l'exploit permet de détourner les clés RSA utilisées pour une connexion SSH. Difficile de penser que ça cible autre chose que sshd?[^] # Re: Je pense que sshd n'était pas visé
Posté par Misc (site web personnel) . Évalué à 9.
En effet, j'avais complètement zappé ce point (alors que je l'ai lu). Ça fait tombé mon analyse à l'eau :(
# Réaction du projet Python
Posté par jeanas (site web personnel, Mastodon) . Évalué à 3.
Rassurante : https://discuss.python.org/t/cpython-pypi-and-many-python-packages-are-not-affected-by-the-backdoor-of-xz/49873
[^] # Re: Réaction du projet Python
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 8.
Même pour les « edge distributions » potentiellement affectées, il faudrait être presque en avance sur son temps. Sur Gentoo la dernière version stable de xzutils était la 5.4.6-r1, qui vient d'être remplacée par la 5.4.2 au cas où :
Mais de toutes façons, contrairement à Debian, openssh n'était pas patché pour l'employer (cf. article du lien). Donc ce risque était probablement nul.
Au passage, il me semble que le script de détection de la vulnérabilité ait un bogue : chez moi il ne retourne aucun message…
De toutes façons, il suffit d'extraire la commande
pour savoir si sshd dépend de liblzma, et savoir si la vulnérabilité est potentiellement présente.
Reste un côté sérieusement inquiétant : si l'attaque s'est trouvée détectée de ce côté-là (un peu par chance si je comprends bien, pour une petite demi seconde…), rien n'empêche que d'autres tentatives aient (eu) plus de succès, et ne trouvent leur chemin jusque dans des distributions publiées. J'imagine que ce genre de scenario est appelé à se multiplier avec les relations internationales de notre époque.
O TEMPORA O MORES.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Réaction du projet Python
Posté par Misc (site web personnel) . Évalué à 6.
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.
[^] # Re: Réaction du projet Python
Posté par roger21 . Évalué à 2. Dernière modification le 30 mars 2024 à 14:13.
la commande ldd n'est pas sûre sur un binaire à la fiabilité incertaine
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27#misc-notes
bon normalement le problème n'est pas sur sshd
# autre suivi du sujet
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
# Et une FAQ sur le problème
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 6.
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
# Le code de la backdoor?
Posté par octane . Évalué à 5.
Nulle part je ne trouve une analyse du code de la backdoor?
Alors on, ça cible les fonctions RSA de sshd donc on se doute que la backdoor permet un bypass de l'authentification, mais est-ce que quelqu'un a extrait le code et fait une analyse complète ?
[^] # Re: Le code de la backdoor?
Posté par aiolos . Évalué à 5.
J'ai cherché aussi (pas énormément, il faut bien dire), et rien trouvé non plus. Si tu trouves, je sous preneur !
[^] # Re: Le code de la backdoor?
Posté par Misc (site web personnel) . Évalué à 4.
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.
[^] # Re: Le code de la backdoor?
Posté par aiolos . Évalué à 2.
Merci, je vais regarder ça.
[^] # Re: Le code de la backdoor?
Posté par octane . Évalué à 5.
Alors. Avoir le dump assembleur, c'est très simple. On fait un coup de objdump -d et hop.
Ou pas.
Ca démarre pas très bien :(
code à l'adresse 0. Et toutes les fonctions sont comme ça:
(vous avez noté que toutes les fonctions ont remplacé leur dernière lettre par un 'a' ?)
Bref. Allons voir du côté des relocations du coup.
LOL PTDR! C'est un véritable challenge, là. Juste à comprendre ce que tu reloges ou pas. J'ai jamais vu ça. Du coup, je comprends mieux les gens qui ne donnent pas une analyse. Rien que reconstruire le vrai binaire, c'est un truc de gueudin. Je préfère aller boire un coup et attendre que quelqu'un le fasse, haha
[^] # Re: Le code de la backdoor?
Posté par Misc (site web personnel) . Évalué à 3.
https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b
semble donner plus d'info
[^] # Re: Le code de la backdoor?
Posté par octane . Évalué à 4.
https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504
donne plus d'infos.
Eeeeet globalement, on s'en fiche de ces reloc. Un outil comme IDA râle un peu, mais finit par ouvrir le binaire, donc c'est bon.
# Réaction officiel du projet/hosteur
Posté par Misc (site web personnel) . Évalué à 5.
https://tukaani.org/xz-backdoor/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.