ALERTE SÉCURITÉ LINUX : Une backdoor dans xz - Point et explications
HTML-код
- Опубликовано: 29 мар 2024
- Script de la vidéo et liens : www.linuxtricks.fr/news/10-lo...
Liens en détails :
Fil twitter : / 1773782014648299702
Blog RedHat : www.redhat.com/en/blog/urgent...
Message d'Andres Freund : www.openwall.com/lists/oss-se...
Red Hat suivi bugzilla : bugzilla.redhat.com/show_bug....
Instructions pour Fedora 40 si concerné : bodhi.fedoraproject.org/updat...
Etat des paquets XZ sur Fedora : packages.fedoraproject.org/pk...
Communication de SUSE : www.suse.com/c/suse-addresses...
Downgrade d'OpenSUSE TW : build.opensuse.org/request/sh...
Message liste de diffusion Denian lists.debian.org/debian-secur...
Etat des paquets XZ pour Debian : packages.debian.org/trixie/xz...
Informations Kali Linux: www.kali.org/blog/about-the-x...
Etat des paquets Ubuntu : packages.ubuntu.com/noble/xz-...
Bug de suivi Gentoo : bugs.gentoo.org/928134
Etat des paquets Gentoo : packages.gentoo.org/packages/...
Informations Arch Linux : archlinux.org/news/the-xz-pac...
Security Arch Linux : security.archlinux.org/AVG-2851
Tweet du CERT : / 1773770991346286940
YCombinator et retour utilisateur : news.ycombinator.com/item?id=...
Tweet du résumé de la CVE : / 1773801887617151386
00:00 Introduction
01:21 Information sur la vulnérabilité par Red Hat
02:30 Rappels sur ce qu'est XZ
03:10 A propos du code malveillant
05:40 Analyses et infos d'Andres Freund
07:00 La problématique de fond
07:20 Réactivité de la communauté OpenSource
07:40 Etat des lieux pour Red Hat et dérivées
08:02 Etat des lieux pour Fedora
09:35 Etat des lieux pour SUSE et OpenSUSE
10:34 Etat des lieux pour Debian
11:50 Etat des lieux pour les dérivées de Debian ... Kali Linux
12:45 Etat des lieux pour Ubuntu
13:58 Etat des lieux pour Gentoo
15:11 Etat des lieux pour Arch Linux
15:56 Que penser de cette actualité ?
18:47 Quel impact au final ?
20:07 Que faire maintenant ?
21:46 A propos de l'auteur du code malicieux
23:00 Pour résumer
23:Outro
--------
Effectuer un don : www.linuxtricks.fr/pages/fair...
Infos utiles comme d'hab :
Quelle distribution j'utilise ?
Fedora Linux avec GNOME
Quel est mon navigateur Internet : Vivaldi
Où me retrouver ? Tout est dans le bandeau de la page d'accueil de la chaine
Mon site web : www.linuxtricks.fr
Ma config PC Fixe :
Carte mère X470 GAMING PRO
AMD Ryzen 5 2600X
16Gb RAM DDR4
AMD Radeon RX 560 (pilote libre amdgpu)
SSD 860 EVO 500GB + SSD 860 QVO 2To
Micro BIRD UM1
PC de TESTS :
Toshiba Satellite C660
Intel Core i3 2330M
6Gb RAM DDR3
NVidia GeForce 315M
SSD Kingston A400 120GB 
Наука
c'est fou, quand même ! On va devoir analyser tous les commits du cybercriminel pour s'assurer que le code est clean ! peut-être que ca va déterrer d'autres backdoor restés sous le radar :0 Et si un paquet est touché, peut-être qu'il y'a d'autres paquets qui sont affectés de la même manière. Peut-être que le criminel a mis sa backdoor sous d'autres pseudos dans d'autres paquets... ca soulève tellement de questions
La problématique est surtout que le code malicieux n'est pas dans le code source.
Et ça c'est problématique : en naïf que je suis, je pensais qu'on ne pouvait pas ajouter de code pendant la compilation, du moins pas sans que ça laisse une mega-trace car c'est une faille béante de sécurité en soi.
Carrément il a peut être autre paquets sûrement.. Le problème il peut incite autre à le faire...
Qui te dit que c'est une personne ? Peut-etre une équipe...peut-être soutenu par un état, ou autre...mysteeeeere
Ces étranges je voit pas l'intérêt. La chose incroyable juste un utilisateur passionnée qui découvre cela bêtement. Au début je pensais que c'etais un poisson avril pour alerter les possibilités de failles dans les snap flatpak ou distrib en Rolling release.
Je crois qu'un AI serait capable de faire le tour des git et de comparer les versions tarbal vs le code source. Je suis sûr qu'on trouverais plein d'anomalie du même genre.
Merci Adrien. Pas concerné avec Fedora mais j'ai pu avertir un ami qui est sous ArchLinux et qui avait la version 5.6.0.
Toujours au top!!!!
Merci Adrien, quel boulot !
LM 21.3, meme avec le noyau 6.5, pas de soucis
Oui RAS, Linux Mint est basée sur Ubuntu 22.04 LTS qui n'est pas concernée)
Ubuntu, la valeur sûre! Après c'est vrai qu'is auraient pu communiquer pour rassurer. Merci Adrien pour ces infos si précises et si importantes 😊
L'auteur a fait aussi le forcing chez Ubuntu : bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2059417
Merci Adrien pour le partage de l'info.
Depuis que je tourne sous Linux, je me pose davantage de questions sur la sécurité informatique et je m'aperçois chaque jour que Windows / linux, les logiciels payants ou freeware, les scripts développés par "la communauté", etc, on ne peut faire confiance aveuglément à personne!
D'une certaine manière, je suis ravi d'avoir eu la réponse à une des questions que je me posais il y a qq mois sur l'installation ou pas de Telegram.
A savoir est ce que le Telegram que je m’apprête à installer correspond réellement à celui dont le code source a été partagé.
Je suppose que ce programme doit contenir des milliers de lignes de codes, le programme est mis à jour très régulièrement, qui est capable et a le temps de vérifier chaque mise à jour!
Ben voilà, j'ai désormais ma réponse!
Effectivement, libre ou pas, payant ou pas, ça change pas grand chose à la sécurité. C'est pas le premier backdoor d'un projet ouvert (ProFDPd pour ne citer que lui en tête), et y'en aura encore. Y'a pas plus de sécurité sur un Windows ou un Linux, d'un truc gratuit ou d'un truc payant, etc.
merci Adrien,pour ta réactivité a tous nous prévenir de cette incroyable histoire,bonne continuation et merci encore.
Merci pour le vidéo, tu es toujours au top et tres concis dans tes explications
Merci pour votre Travail.
🙂👍
Merci !
Un remerciement pour l'info Adrien !! Etre réactif dans l'installation des maj systèmes, navigateurs et logiciels.... !!
Oui !
merci adrien, le clin d oeil a gentoo, cool! pas capté pourquoi ils ont mentionné la 5.4.3
Bonjour, merci pour l'information , j'avais ce paquet sur un ordinateur Opensuse Thumbleweed portable que je ne branche pas tous les jours, aprés mise à jour le paquet à rétrogradé de version.
Merci pour l’info
Super vidéo Adrien, merci pour ton super taf.👍😎
Merci , détaillé sans trop l'etre , c'est excellent
Regarde mon commentaire
Merci pour toutes ces informations pertinentes
Avec plaisir :)
Salut Adrien, merci pour toutes ces informations
Merci !
Merci de l'information! j'avais vu rapidement hier c'est rassurant de voir toutes les équipes réagir rapidement !
Oui, c'est une des forces du libre
merci pour ces infos.
De rien, j'espère que c'était clair !
Bonsoir merci pour l'info je l'ai vue passé sur archlinux j'ai mis a jour ce soir je réinstalle tout.
Personne n'a pensé à se débarrasser de xz c'est dommage tout en sachant que sa touche le noyau sa craint... Que va faire l'équipe du kernel vont il utilise une autre alternative pour la compression... Le problème est bien plus grave encore...
Merci pour la communication 👍
:)
Merci Adrien pour cette info de mise en garde
:)
Merci Adrien, info importante effectivement
Merci !
Bonjour, merci Adrien. Je viens de faire un tour sur le site Alpine linux qui ne parle pas de la CVE et precise pour la branch 3.19 xz 5.4.5 et pour la edge xz 5.6.1 mais elle est "Flagged"
Merci !
C'est quand même sacrément chiadé la méthode d'implémentation de la backdoor, le truc planqué à l'intérieur d'un binaire servant de test et l'injection n'apparaissant à la compilation que dans des cas relativement précis. La lecture du post d'Andres Freund est vraiment super intéressante. Il ne se dit ni expert en sécu, ni reverse engineer, mais il n'est clairement pas tombé du nid hier héhé. Bravo et merci à lui en tout cas. Ça soulève évidemment des questions, comme la présence d'autres backdoors éventuelles ne mettant en cause ni sshd ni systemd, y compris dans des versions antérieures à la 5.6.0 de xz.
Merci Adrien en tout cas, toujours didactique. 👍 Et la réaction générale de la communauté GNU/Linux dans son ensemble fait plaisir à voir je trouve.
_Sauf le mutisme de Canonical évidemment, mais bon, eux, à force, on commence à être blasés par leurs réactions, ou par leur absence de réaction._
Effectivement, c'est aussi fascinant que pervers, non seulement la partie technique, mais aussi la partie sociale de l'affaire où le gars a patiemment frayé son chemin et mis la pression jusqu'à ce qu'il puisse enfin asséner le coup final.
Attention avec la commande xz --version, si un logiciel est compromis, il est possible que le résultat de l'affichage de la version le soit aussi (visiblement, ce n'est pas le cas ici avec xz)
Bon Vidéo. En passant Mageia 9 est à la version 5.4.3
Merci
Merci pour la communication Adrien. edit : Je suis utilisateur de arch en endeaveour. Il faut bien sûr faire les mises à jour au plus vite mais pour rassurer je précise que contrairement à Debian (et d'autres distributions qui en dépendent) sur arch, openssh n'est pas patché pour supporter la notification systemD. Libsystemd dépend de lzma. (normalement openssh n'utilise pas directement liblzma) .
donc arch ne lie pas directement openssh à liblzma et le malware , s'il était bien présent pendant un certain temps dans les dépots, était incapable d'agir. (source : news de arch)
:)
Merci pour toutes ces infos donc en production c'est nada trop de 🎉🎉🎉 sur les réseaux sociaux pour ça
Merci pour cette vidéo informative.
J'aimerais toutefois poser une question pour approfondir un point abordé. Vous avez mentionné que la faille de sécurité est présente uniquement dans la version compilée distribuée sur GitHub, et non dans le code source original. Est-ce à dire que les distributions telles que Debian, Fedora, etc., ne compilent pas le programme à partir de ce code source mais utilisent plutôt les binaires qui sont directement publiés ?
Pour la précision, le téléchargement "Code source" c'est comme le contenu du "git clone" au moment où une "version" a été créée.
Tu peux ajouter des fichiers supplentaires (c'est ce qui a été fait). On ne peut plus les télécharger mais "je pense" que dans le cas ici, c'est "simplement" le contenu du git clone avec des fichiers de tests en plus, compressé dans plusieurs formats différents.
C'est donc aussi un code source.
Pour générer un DEB ou un RPM, c'est quasiment toujours du code source qui est utilisé, et le binaire est compilé au moment de la création du RPM.
C'est ça qui rend le cas difficile à étudier, c'est que là le tar.gz contient des petites modifs non présentes dans le git.
Quand je fais des packages RPM pour Fedora ou avant pour Gentoo dans mon overlay, je prenais toujours le "tar.gz" estampillé "Code source" ;)
@@AdrienLinuxtricks de quoi ?
Merci pour l'info! J'utilise mon pc avec 3 systèmes au démarrage: (Win11/Nobara39(fedora)/Opensuse Tumbelweed) Donc effectivement pour Opensuse Tumbelweed , il y a eu une grosse mise a jour pour revenir en arrière! D'ailleurs le serveur était surchargé.
Super système de démarrage une option est en trop devine laquelle 😂 j'espère que tu as pas eu de problème
@@otechdo Non aucun problème merci! Je suppose que tu parle de Windows pour l'option en trop, je l'utilise uniquement pour la virtualisation d'android (bluestacks et memu play) malheureusement aucun programme équivalent sous linux!
Merci pour la vidéo, j'ai installé Kali hier soir et Artix avait la 5.6.1. Kali était étrangement en 5.4, mais j'ai dû faire le passage à la 5.6.1-2 sur Artix
Kali avait probablement déjà fixé le souci.
Et pour les BSD ?
Merci Adrien pour les explications. Avec un pare-feu, on est protégé ou non ?
Le pare-feu, sous Linux permet généralement d'interdire le trafic entrant, mais autorise le trafic sortant dans sa totalité. Suivant comment la prise de contrôle peut se faire :
- Si c'est sshd qui est corrompu, le port 22 étant ouvert pour une connexion classique : ça ne protège en rien
- Si c'est une connexion de la machine qui se fait sur un serveur externe puis que de celui-ci la connexion rentre : ça ne protège en rien (c'est comme ça que fonctionne Teamviewer ou Anydesk, ce qui évite d'ouvrir des ports dans la BOX)
- Si ça ouvre un port différent pour se connecter (par exemple 12345) là le pare-feu peut protéger
merci
mais la dernière phrase n est pas claire pour moi
comment il fonctionne?
Peut tu faire une playlist CVE / CYBER ? BISOUS
J’avais upgradé une Silverblue 39 en 40. Après un gros freeze sur Sypheed (qui m’avait bloqué complètement le système), je suis redescendu en 39 via un rollback.
Dans ce genre de cas de figure, il vaut mieux réinstaller ?
Avec Silverblue tu n'as pas besoin de réinstaller
Salut Adrien, merci pour la vidéo, comment fais-tu pour avoir un Twitter à l’ancienne ?
Il a fait une vidéo sur le sujet
Oui j'ai fait une vidéo sur le sujet. Il s'agit d'une extension à laquelle je contribue (open source) : Old Twitter
Bonjour . Es que Linux mint Mat est concerné ? Merci pour l'info
La dernière version stable de Mint, la 21.3, nom de code Virginia, est basée sur Ubuntu 22.04 LTS, donc non, à priori pas concernée.
Un xz --version te donnera le numéro de version utilisée, à priori la version 5.2.5 sur la Jammy qui sert de base à Viriginia, donc très antérieure à la 5.6.0
Les distributions n'utilisent pas le code source des différents composants pour construire les packages !?
Les distributions utilisent bien souvent les paquets .deb ou .RPM ou .apk ou autre pour procéder à l'installation des programmes. A ma connaissance Gentoo compile depuis les sources mais il semble affecté... Compiler depuis les sources nécessite plus de temps, un navigateur web ou libre Office, c'est plusieurs heures sur mon vieux core i3.
Super video ❤
Merci !
Merci Adrien 👍🏻 Je suis curieux de savoir ce qui va arriver au concepteur de ce code malveillant
Il sera embauché par une organisation cyber criminelle ou une agence d'un gouvernement peu recommandable. A moins qu'il n'en fasse déjà parti! auquel cas il ne risquera strictement rien
En tout cas son compte github est bloqué (tout comme le dépôt on l'a vu) mais aussi le compte github du mainteneur historique :(
totalement anonyme... aucun controle...
Hello,
De ce que j'ai compris de l'attaque, si vous avez eu une version compromise de xz, mettre à jour le package ne corrigera pas le problème. Il faut réinstaller tout votre système. Voici pourquoi.
L'attaque n'est en effet pas contenue dans l'utilitaire lui même. C'est beaucoup plus fourbe que ça. L'attaque est contenue dans les scripts de compilation, exécutés au moment du build de la distrib, afin d'altérer d'autres paquets. En particulier le loader système ld. C'est lui qui se retrouve corrompu, tandis que xz en lui-même reste OK. C'est lors de sa compilation qu'il vient corrompre l'intégrité d'un autre élément clé de l'OS de manière à ce que, à son tour, il altère dynamiquement l'intégrité de sshd lors de son lancement - alors que sa version binaire sur disque est OK. C'est très vicieux... et très bien pensé il faut l'admettre.
Oui, c'est pour cela que je dis qu'il est plus sûr de tout réinstaller, comme dans toute compromission
Cette explication n’a aucun sens. Si c’est lors de la compilation pour une distribution, le paquet glibc est déjà compilé. Cela ne peut donc fonctionner que pour ceux qui utilisent des distributions où la compilation est faite chez l’utilisateur.
Si c’est une injection lors de tests, et si l’on a trouvé le code malicieux, on sait exactement ce qui a été altéré et cette altération est éphémère.
@@0okaze je te plussois... a quel moment une compile une lib ? generalement on dl des binaires... a vue de nez, l’attaquant devait ciblé les fondeurs....
Bonjour, y a-t-il une suite juridique à l'encontre de l'auteur malveillant ? Quelles étaient ses motivations ?
Compliqué. Le compte github concerné a été ciblé, on le voit dans les sources données par Adrien, mais concernant le ou les détenteurs du compte, c'est autre chose. Le compte gh, ou du moins la ou les machines du détenteur, a peut-être été également compromis. Sans parler du fait que suivant la localisation géographique de la personne, ou des personnes, bonne chance pour appliquer des éventuelles suites juridiques.
@@Nadi_Games curieux... la fin est coupé ?
a priori il n'y aura pas de suite... sauf si on tombe pile sur le mec...
@@oolmfoxz8170 Comment ça coupé ? Si mon message semble tronqué, recharge la page, parfois YT a des soucis actuellement, pour les messages qui dépassent 4 lignes, il affiche juste ... mais pas «Lire la suite».
Sinon oui, je finis mon message en disant que suivant l'identité de la personne, sa nationalité et/ou sa localisation, c'est parfois pas évident de pouvoir le poursuivre. Et encore faut-il être certain que c'est réellement le détenteur du compte qui est à l'origine de la backdoor, et non pas que son compte ait été corrompu par quelqu'un d'autre.
(même si les échanges de mails tendraient à laisser penser le contraire, mais bon, sans tout l'historique, c'est compliqué de se faire une idée uniquement sur les pull requests.)
merci pour ce partage info sécurité utile ça donne envie de compiler les sources plutôt que de passer par les paquets précompilés... 🤔
Oui .. ou non.
Seulement en clonant les sources du git t'aurait permis d'éviter le souci.
Si tu prenais les sources en prenant le "tar.gz" tu avais le code malveillant
Merci pour l'info.
Je ne comprends pas ce qui a poussé cet individu à faire ça.
Mettre une backdoor dans Kali, c'est une porte ouverte à énormément de réseaux internes d'entreprises, avec en prime un petit feedback des différentes vulnérabilités.
On ne saura jamais.
la gloire, l'argent, le fun ?
Le développeur impliqué se faisait appeler Jia Tan, ça sonne très chinois.
Si tu cherches, Jia Tan est une personne qui existe (une chercheuse mais pas du tout en info), mais je doute que ce soit elle derrière. C'est juste un pseudo. Mais effectivement, le nom existe.
Personnellement, je ne me fierais absolument pas à la consonance.
Ce serait bien trop facile d'orienter la suspicion vers telle ou telle communauté en fonction du choix d'un pseudo.
@@Nadi_Games Tout à fait. D'un autre côté, c'est à la fois sournois et pas très gentil, car la "vraie" JIan Tan a même son site web, donc tout le monde a dû tomber sur son site ces derniers jours.
Salut Merci
:)
Merci Adrien pour cette alerte de sécurité !
Ouf, la distribution Artix Linux n'est pas concernée !
Bonjour,
Bah moi qui est sur Arch Linux pas bonne nouvelle après c'est une station de travail j'ai fais la mise à jour de mon System : sudo pacman -Syu, j'ai maintenant la version 5.6.1-2
mais je me pose la question si je ne vais pas le réinstallé..
Ah les Rolling release..
Et Merci Adrien pour cette info Capital..
PS : je vais aussi vérifier des éventuels Root Kits.
Pas de soucis.
J'ai dit que le plus propre était de réinstaller car on ne sait pas si les éléments vérolés ont fait autre chose sur le système.
Après dans le contexte pro, si j'étais touché par ça, je prendrais aucun risque ;) Mais ça, c'est parce que j'ai der serveurs à risque
A priori sur Arch pas de souci au niveau de cette backdoor précise :
"openssh n'utilise pas directement liblzma. Cependant, certaines distributions comme Debian patchent openssh pour supporter les notifications systemd, et libsystemd dépend de lzma. Arch ne fait pas cela, donc ce vecteur d'attaque n'est pas possible."
Mais ça ne change rien au risque en général, c'est clair.
idem manjaro
@@fabfab5156 j'ai meme pas liblzma sur ma manjaro...
Comme quoi on se met à jour pour se mettre en sécurité et c'est là qu'on se prends une porte ! La sécurité dans l'internet, une légende ? (bon, je force un peu le trait, mais les attaques se font de plus en plus fréquentes et parfois même sur des boites super sécures, non?). Et plus c'est complexe, plus c'est fragile... allez, souhaitons-nous bonne chance ! :))
Pour void linux, ils ont fait, hier, un downgrade vers la version 5.4.6_2 lors la mise à jour du système
OK possiblement concerné aussi
Bonsoir. Peux tu m'aider ? Jai un redmi 9a . Mon navigateur est chrome. À la suite d'une mauvaise manipulation, le navigateur mi à remplacer chrome. Je veux remettre chrome. Merci de m'aider.
dans chrome-parametre... il y a "navigateur par defaut"...
pour lancer chrome... utilise le termlnal...
Salut et merci pour ta vidéo je suis sur Fedora 40 mieux vaut que je revienne sur la version 39 merci pour ces informations
Fedora 40 n'a été concernée que succintement et dans les dépôts updates-testing. (Dans l'ISO de la Beta, la version 5.4 est présente)
Si tu ne les as pas activés tu es tranquille
Tu peux vérifier si tu as eu la MàJ vers la version 5.6 à un moment donné avec :
grep xz /var/log/dnf.log
Visiblement mon commentaire s'est fait autokill par youtube, je ne sais pas pourquoi.
Je disais, sur Arch, il disent :
"openssh n'utilise pas directement liblzma. Cependant, certaines distributions comme Debian patchent openssh pour supporter les notifications systemd, et libsystemd dépend de lzma. Arch ne fait pas cela, donc ce vecteur d'attaque n'est pas possible."
Sous réserve d'absence d'autre code malicieux, les utilisateurs de Arch sont normalement potentiellement safe ce coup-là.
après lzma ne veut pas nécessairement dire xz mais ça peut être l'ancienne version de l'algo fournie par 7zip. Pour preuve, un bon vieil outil comme clonezilla propose à la fois lzma4 et xz comme option de compression. Malheureusement, c'est libzlma5 qui est en dépendance dans Debian, càd la version xz. Après j'ai pas fouillé davantage mais c'est possible que systemd utilise l'ancien algo et que xz est appelé en mode legacy, ce qui serait une erreur des mainteneurs Debian.
D'ailleurs le format xz est depuis longtemps décrié en terme de fiabilité.
Team arch endeavor
Normalement, c'est corrigé, mets bien ton système à jour :)
Vérification effectuée de mes version xz sur mes linux mint,
Niquel merci Adrien
En fait en dehors d'une machine virtuelle qui est démarré très très rarement, je suis tranquille.
Linux Mint étant basée sur Ubuntu 22.04 (ou Debian stable pour LMDE) RAS
Tu peut pas traduire les pages en Français
Heu, il existe des antivirus sous Linux. Ils ont rien vu du coup ? Allo Eset ?
Jte déconseille les anti-virus. Même si les appli Linux sont généralement open source et safe. Y a rarement des attaques sur Linux parcontre tu peux utiliser des utilitaires comme Fail2ban qui vérifie les connexions suspecte.
ce serait un APT 19
les entreprises et les professionnelles ainsi que les contributeur devrai porter plainte afin de condamner cette personnes ! et ne pas laisser lettre morte !
Enquêter serait effectivement utile, ce qu'on découvrirait pourrait être assez perturbant.
Cela dit, une bonne partie de la responsabilité incombe aux distributions qui ont utilisé massivement xz depuis des années sans réellement regarder de près le projet - c'est à peine maintenant qu'ils le font. Il n'est toujours pas impossible qu'il y ait d'autres parties problématiques qui sont passées sous le radar.
@@joseoncrack ouai c'est assez fou que les mainteneurs ne font pas un git-clone et prennent les archives sans se poser de questions. Espérons que ce genre d'incident va les faire réfléchir sur leurs méthodes de packaging.
@@PainterVieraxOui, ce serait un bon début, mais ce n'est pas le seul problème: le packaging est une chose, mais l'implémentation même en est une autre. Trop peu de développeurs regardent réellement de près les librairies dont ils choisissent de dépendre, d'une façon générale. Qui avait déjà regardé le code lui-même de xz, et même sa spécification? Très très peu. Il y avait eu une problématique similaire avec log4j. Pour faire simple, on ne sait pas ce qu'on utilise et on croit que ça va bien se passer parce que "'tout le monde" utilise la même chose. C'est fondamentalement un anti-pattern en terme de sécurité.
@@joseoncrack J'entends bien. Après ici y a pas vraiment d'alternatives si un dev ou un projet veut implémenter le support de lzma5 de manière générale. Pas beaucoup de choix non plus quand systemd lui-même force son utilisation.
Des gens ont déjà regardé les specs et fait des tests du format xz (pour ça que perso je préfère le bon vieux lzma4 pour archiver de manière fiable). Le problème ici c'est pas le code mais bien l'utilisation d'archives et l'excès de confiance sur toute la chaine. Le code sur github a bien été scruté.
Enfin le fait que tout le monde utilise la mm chose c'est pas nécessairement un soucis de sécurité en soi. Certes ça amplifie la portée d'une telle attaque mais ça permet aussi de réduire le code à auditer et de focaliser davantage de sur celui-ci. Dans un OS type cathédrale, cette épée à double tranchant a même tendance à mettre encore plus la pression sur la rigueur du travail d'audit. Encore une fois, c'est un problème de culture des mainteneurs qui oublient que parmi le bazaar GNU/Linux leurs églises sont très populaires et parfois les fondations ne sont pas si différentes les unes des autres.
@@joseoncrack et tu fais comment quand ton projet inclus 30 voir 50 libs ?
Le développeur a rajouté un code bidon pour soit disant tester des architectures en ajoutant un point qui désactive le sandbox qui laisse vulnérable l’accès au backdoor
En rajoutant un point le code ne compile plus en runtime et donc le sandbox ne vas plus fonctionner
Un développeur débutant peut s’en apercevoir tout de suite c’est ce qui confirme que c’est intentionné en plus du code bidon qu’il a rajouté (prétexte non justifiée)
@@Agagh j'ai lu en diagonal... mais clairement...
Merci pour les explications claires, mais ça fait un moment que j'ai du downgrader ma Debian pour revenir à une stable,
perso je viens à peine de faire l'upgrade de bullseye à bookworm. Tant que ça marche on touche pas.
Bon, il va falloir que la NSA réécrive une nouvelle backdoor, c'est malin, pfff ! 😂
linux c quand meme bcp basé sur la confiance...
ca vas etre ultra chiant si on doit audité tout le code a chaque maj...
ca peut etre la mort des rolling release à terme...
mais surtout une grosse monté en paranoia sur les contributeurs... certain projet sensible ne devrait pas accepter de contributeurs annonyme...
L'informatique n'étant pas mon domaine de base toute la partie "mécanique d'ingénieur sous le capot" m'échappe complètement, donc désolé si mon questionnement pourra sembler primaire à certains mais il y a un truc qui m'échappe:
- si le code source est saint, comment une compilation peut-elle engendrer un code malicieux à partir d'un code source saint?
- si une compilation peut engendrer du code malicieux à partir d'un code source saint, quel interêt d'avoir un visu sur le code source puisque ce n'est donc aucunement un gage de sécurité ?
- n'importe quel code source peut ainsi paraitre saint tout en cachant une compilation malicieuse ?
Pour résumer le concept d'open source n'est aucunement un gage de sécurité supplémentaire par rapport aux codes fermés ???
parce que derrière, la personne met à disposition un fichier compilé avec les sources modifiées. Si une personne compile elle même les sources qui elles sont fiables elles ne seront pas affectées.
"Pour résumer le concept d'open source n'est aucunement un gage de sécurité supplémentaire par rapport aux codes fermés ???"
Il faut se poser la question en effet. Beaucoup de personnes ont accès au code source, par contre je serais curieux de savoir le pourcentage de ceux qui vont aller voir ce qu'il y a dedans.
il y a un tas de truc a faire entre le code source et la compilation
par exemple verifier la platforme (le CPU) ou activé ou desactivé certaine fonctionnabilité... a priori, l'attaque ce situe justement dans les "trucs a faire entre"...
opensource vs codes fermés ? ok... on trouve des rigolos pour ajouter des backdoors dans des projets opensource... certes... mais aux yeux de toute le monde...
rien ne dit qu'il n'y a pas 150 backdoors dans un code fermé... que ca soit volontaire ou non... et la, a part du reverse (donc des semaines de boulot) c mort pour savoir...
d'autant qu'avec le source, il y a moyen d'automatisé des veilles...
par exemple : verfier qu'il n'y a pas d'utilisation de lib qui n'ont rien a foutre la...
Ma question dans un futur proche sera qui a fait cela réellement cette backdoor et pourquoi ? Oeuvre d'un programmeur amateur ou une commande dans un but précis ?
Commande cela d'une agence a 3 lettres ? Les backdoors c'est merveilleux pour l espionnage et autres....
il faudrait regarder le code de plus pres... si la backdoor est un affaiblissement du chiffrement ou une porte dérobée bien sale...
les etats on tendance a privilégier l'affaiblissement du chiffrement pour que la backdoor soit tout de meme bien chiante a activer...
Zero day is a fitur 😂
Sait-on pourquoi il a fait çà ? Pour une exploitation pour ses intérêts ou est-ce une "petite main" ?
Non, on ne sait pas, et on ne le saura probablement jamais je pense
Pas normal en effet... Comment un tels individus peut t'il faire du mal à une communautées qui est contre ces valeurs.
On ne saura jamais :(
@@AdrienLinuxtricks on va peut-être en savoir plus puisqu'une enquête est en cours sur le pseudo visé. Il faut savoir qu'actuellement il faut rester très vigilant, surtout durant les week-ends prolongés.
Merci Adrien, peut-on y voir la main du FSB derrière le hacker en question ?
Ça c est les Russes c est sur
ça peut aussi être un moyen de détourner l'attention, un conseil, restez vigilent durant les weekends prolongés.
😂😂😂
non... il n'y a pas de bébé decapité dans l'affaire...
Merci !