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: 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 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

AutoWG: a simple Bash script to connect two devices with Wireguard

I made today a quite simple BASH script that allows to connect two devices running Wireguard (tested with Debian Linux 12, but should work with any device) You can check it out (and fork it if you want) in this Gitlab Page This is the source code as of now, but I could modify it later (any suggestions are welcome) : #!/bin/bash # # AUTOWG written by Hamdi KADRI # No copyright in any form or kind # This script is intended to create configurations for # a point-to-point Wireguard connection between a server # and a client (/30 network) # # Step zero: declare configurations as variables servercfg="[Interface] Address = <serverwgIP> SaveConfig = true ListenPort = <port> PrivateKey = <server-privatekey> [Peer] PublicKey = <client-pubkey> AllowedIPs = <clientwgIP> " clientcfg="[Interface] PrivateKey = <client-privatekey> Address = <clientwgIP> [Peer] PublicKey = <server-pubkey> AllowedIPs = 0.0.0.0/0 EndPoint = <serverIP...

HK blog

Rechercher dans ce blog