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.
# Je pense que sshd n'était pas visé
Posté par Misc (site web personnel) . En réponse au lien Backdoor in upstream xz/liblzma leading to ssh server compromise. É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.