CVE-2024-3094: Un backdoor médiatisé ?

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

Posts les plus consultés de ce blog

GNS3 on Manjaro/Arch Linux: How to create virbr0 for NAT to work

Problem: You can't add a NAT connection to your GNS3 simulation, and you get the error : "ERROR template_manager:226 Error while creating node from template: NAT interface virbr0 is missing, please install libvirt" Steps to resolve: 1- Create a file named /tmp/default.xml 2- Paste this content and save: <network> <name>default</name> <bridge name="virbr0"/> <forward mode="nat"/> <ip address="192.168.123.1" netmask="255.255.255.0"> <dhcp> <range start="192.168.123.2" end="192.168.123.254"/> </dhcp> </ip> </network> 3- Execute the following commands in your shell : virsh net-define /tmp/default.xml sudo virsh net-start default sudo virsh net-autostart default

GNS3: Simulating a 100% opensource site2site VPN using Wireguard, VyOS and OpenVSwitch

This is something I had in mind but didn't find the time to accomplish before. It just took a very cold day to convince me that I have to play with Wireguard on VyOS. I used GNS3 of course, on my personal Linux laptop to create this setup. Of course the performance was not that great since it is just a simulation. In real life, I am using Wireguard on a 10 years old Raspberry Pi Model B and amazingly with just a 700MHz single core ARM CPU and less than 512 MB of RAM I had a decent and stable permanent Wireguard tunnel. (My bandwidth would reach 24 Mbps without issue) Back to my simulation, this is what it looks like : Quick explanation: the VYOS routers labeled IPERF1 and IPERF2 are only used for an iperf3 test, which was able to reach about 50 to 60 Mbps each time. It ain't much but it was honest (and free) secure bandwidth! I won't get into the details of this setup but I will just post the two most important configurations : R-East and R-West : #### VYOS WireGuard Site...

GNS3 vs VM: iperf3 test for VyOS

In my last post I tried to simulate a site2site VPN connection using Wireguard via VyOS, my favourite router. It was very easy to implement but the performance was not that great on GNS3. It was not a VyOS issue at all, GNS3 is just a simulation tool and we can't expect real world performance in it, even if it uses Qemu and Linux virtual networking for that end. To prove that, I made the following simple iperf3 test using 3 VyOS routers on GNS3 : No VPN, just simple routing via connected routes through VyOS1.3-3. The result was similar to my Wireguard throughput test, of course considering the header size of Wireguard packets : In my Wireguard test, I reached a bitrate of 53.8 Mbps, which is almost 76% of total bandwidth, and it's a good result, but I had to verify if VyOS is able to route at a greater bitrate. For just that, I created a VyOS VM on VirtualBox and connected two other VyOS VMs to it's interfaces, and made an iperf3 test. The result was clearly better : Reach...

HK blog

Rechercher dans ce blog