Je propose ici mon avis sur la vulnérabilité "liblzma" du package "xz" que je trouve très "overrated".
Il semble que le backdoor CVE-2024-3094 a été très mediatisé, bien que l'impact n'est pas très significatif sur les serveurs en production. Je comprends l'importance des systèmes Linux (qui font tourner Internet) mais ça donne aussi un faux sentiment que la philosophie Opensource a échoué.
- D'une part, les distributions "production ready" qui sont en général connues en tant que "Stable" ou même "LTS" ne déploient pas les dernières versions de XZ. Exemple : Debian, Ubuntu Server 22.04 LTS , RedHat Enterprise Linux, SUSE Linux Enterprise Server, etc. ont toutes des versions de XZ plus anciennes que celle impactée. C'est une philosophie de ne pas déployer les dernières versions des packages avant d'avoir une assurance totale de leur stabilité, surtout dans les environnements de production et les serveurs d'application publics.
Ubuntu : https://packages.ubuntu.com/search?keywords=xz-utils
RedHat : https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users
SUSE : https://www.suse.com/c/suse-addresses-supply-chain-attack-against-xz-compression-library/
Debian : https://security-tracker.debian.org/tracker/CVE-2024-3094
- Les distributions qui ont intégré ce package infecté pour une très courte période sont en général les distributions de test, les distribution instables (très populaires en tant que desktops et pas serveurs) et certaines distributions dites "rolling release" (tel que Arch) qui ne sont pas en effet des distributions à utilisation d'entreprise. [Update : Arch n'a pas lié liblzma à SSH et ainsi n'a jamais été vulnérable à ce CVE]
- La correction du CVE en question n'a pris que quelques heures après sa découverte
- Le service impacté (SSH) n'est pas en effet un service de production mais de management (à l'exception du SFTP) et de nature il est très déconseillé de le publier sur internet sans avoir au moins un filtrage ACL. Le scénario d'avoir OpenSSH avec XZ à la version 5.6 sur un serveur de test "instable" déployé sur internet est un peu marginal.
- Les pratiques habituelles de déploiement du service SSH en général recommandent la désactivation du login "root" (dans le cas du SFTP on désactive le login en spécifiant /bin/nologin comme shell utilisateur)
Commentaires