• # Annonce chez Red Hat

    Posté par  . Évalué à 10.

  • # Sur HN, LWN et ailleurs

    Posté par  (site web personnel) . Évalué à 7.

  • # Je pense que sshd n'était pas visé

    Posté par  (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.

  • # Réaction du projet Python

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    • [^] # Re: Réaction du projet Python

      Posté par  (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ù :

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

      O TEMPORA O MORES.

      « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

  • # autre suivi du sujet

    Posté par  (site web personnel) . Évalué à 10.

  • # Et une FAQ sur le problème

    Posté par  (site web personnel, Mastodon) . Évalué à 6.

  • # Le code de la backdoor?

    Posté par  . É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  . É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  (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  . Évalué à 2.

          Merci, je vais regarder ça.

        • [^] # Re: Le code de la backdoor?

          Posté par  . Évalué à 5.

          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

  • # Réaction officiel du projet/hosteur

    Posté par  (site web personnel) . Évalué à 5.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.