Rsync permet la synchronisation des fichiers et est souvent utilisé par les distributions Linux pour la sauvegarde distante ou la création de points de restauration, dans des outils comme Timeshift. Une nouvelle version 3.4 vient de paraître, avec à son bord des correctifs pour six failles de sécurité, dont une critique. Elles ont été découvertes par des chercheurs de l’équipe Google Cloud Vulnerability Research.
On trouve ainsi deux failles dans le serveur Rsync, CVE-2024-12084 et CVE-2024-12085, respectivement un débordement de mémoire tampon allouée dans le tas et une fuite d’informations à partir de données non initialisées de la pile. La première est critique, avec un score CVSS3 de 9,8.
La combinaison des deux permet à un client anonyme avec simple accès en lecture de contourner l’ASLR (address space layout randomization) et de déclencher l’exécution d’un code arbitraire sur le serveur. Ces failles ont été introduites dans Rsync 3.2.7.
On trouve également quatre failles dans le client Rsync :
- CVE-2024-12086 : permet à un serveur malveillant de lire des fichiers arbitraires
- CVE-2024-12087 : permet de créer des liens symboliques dangereux
- CVE-2024-12088 : permet d'écraser des fichiers arbitraires dans certaines circonstances
- CVE-2024-12747 : affecte la façon dont le serveur Rsync gère les liens symboliques
Toutes ces failles sont corrigées par la version 3.4 de Rsync, en déploiement dans les distributions Linux depuis hier soir. Il est recommandé de mettre à jour son système aussi rapidement que possible.
Commentaires (19)
Abonnez-vous pour prendre part au débat
Déjà abonné ? Se connecter
Cet article est en accès libre, mais il est le fruit du travail d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles
Profitez d’un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousAujourd'hui à 09h02
Quant à la première faille évoquée (CVE-2024-12086), elle ne semble pas spécifique à Linux du tout.
Modifié le 15/01/2025 à 09h32
Dans le même genre, je déteste la configuration de Cron... C'est d'un
barbantbarbu...Autant niveau desktop, il y a eu des progrès notables, autant niveau cli, les développeurs restent coincés dans des réflexes d'accessibilité d'un autre âge...
Aujourd'hui à 09h50
Aujourd'hui à 09h53
Juste c'est stable et ça marche :)
Modifié le 15/01/2025 à 14h29
Beaucoup restent néanmoins imbuvables pour ceux qui mettent les mains dedans pour la première fois. CRON en est un bon exemple, d'ailleurs.
Ce n'est pas parce que c'est du CLI et que ça s'adresserait surtout potentiellement à des power users, qu'il ne faudrait ni tenir compte de l'accessibilité/lisibilité, ni de l'ergonomie.
Si on écoute ceux qui utilisent ces outils depuis des lustres, habitués, évidemment que ça leur convient, de même que photoshop est plébiscité alors que son ergonomie est à ch... et pérpétue encore ses erreurs de jeunesses pour ne pas casser les habitudes !
Et le souci sous Linux n'est pas reservé qu'aux programmes CLI, les GUI aussi manquent souvent d'accessibilité, même si pour une majorité de logiciels, ça a bien progressé !
Aujourd'hui à 09h55
Aujourd'hui à 10h05
Aujourd'hui à 10h23
Aujourd'hui à 10h49
Par contre, en recherchant rsyncd sur google, je suis tombé en premier lien sur une doc ubuntu qui ne dit pas qu'il faut modifier ce point et dit juste de lire le man de rsyncd.conf.Je pense que la plupart de ceux qui lisent ça passera à côté du problème.
Aujourd'hui à 11h11
Aujourd'hui à 11h22
Et oui j'avais zappé le fait que c'était pas authentifié par clé SSH quand tu le lançais comme démon (en même temps c'est logique).
Par contre j'ai un nom de user spécifique et je viens de rajouter un mot de passe.
Le fait que ça passe en clair n'est un problème que si tu penses que ton FAI espionne par défaut ET que les données sont aussi en clair & valorisées.
Si une des machines au bout est déjà compromise le chiffrement en transit n'apporte rien, il me semble
Aujourd'hui à 11h48
Anciennement, pour accélérer mon rsnapshot, je le faisais passer par un ssh avec un chiffrement arcfour (le plus rapide, de loin). Avec les processeurs actuels, la vitesse n'est plus vraiment un problème et je reste avec l'option par défaut (arcfour est déprécié, de toute façon).
Aujourd'hui à 11h34
Alors selon le besoin, à titre perso, c'est du rsync en local inter-machine
Si je passe over internet avec du backup de data sur un server perso => rsync over ssh par clé
mais j'ai 0 daemon rsync qui tourne....
Par contre, le nombre de serveurs ouverts sur le net avec rsync : tous les miroirs Linux qui supportent rsync + les lv0/master de distribution ?
Il y a donc potentiellement des cibles critiques
Arch :
Debian : https://mirror-master.debian.org/status/mirror-status.html
Ubuntu : https://launchpad.net/ubuntu/+archivemirrors
par exemple... et tous les scripts de sync des mirroirs masters => slaves : only via rsync (alors certains je sais qu'il y a une restriction par IP du slave => master, suffit d'avoir un slave compromis...)
Aujourd'hui à 12h37
Aujourd'hui à 14h54
Aujourd'hui à 15h24
Aujourd'hui à 15h54
J'ai essayé rsync pour de la synchro, mais je n'ai pas réussi à gérer comme il faut l'effacement de fichiers. Je pense qu'il faut forcément passer par un VCS pour ça.
Modifié le 15/01/2025 à 15h49
Edit : Ahah, je viens de voir la question opposée de @Jarodd 🤣
Edit 2 : après quelques secondes de recherche, j'ai trouvé ça :
Using rsync without ssh 😱
Modifié le 15/01/2025 à 12h09
(Linux Mint 21.3 et donc base ubuntu 22.04)