IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    8 428
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 8 428
    Points : 197 256
    Points
    197 256
    Par défaut Une backdoor découverte dans un utilitaire de compression Linux répandu brise les connexions SSH chiffrées
    Une porte dérobée découverte dans un utilitaire de compression Linux très répandu brise les connexions SSH chiffrées,
    Red Hat demande de « cesser immédiatement d'utiliser toute instance de Fedora Rawhide »

    Des chercheurs ont découvert une porte dérobée malveillante dans un outil de compression qui s’est infiltré dans des distributions Linux largement utilisées, notamment celles de Red Hat et Debian. L’utilitaire de compression, connu sous le nom de xz Utils, a introduit le code malveillant dans ses versions 5.6.0 et 5.6.1 selon Andres Freund, le développeur qui l'a découverte.

    Aucun rapport connu ne fait état de l'intégration de ces versions dans les versions de production des principales distributions Linux, mais Red Hat et Debian ont signalé que les versions bêta publiées récemment utilisaient au moins l'une des versions rétroactives, en particulier dans les distributions Fedora Rawhide et Debian testing, unstable et experimental. Une version stable d'Arch Linux est également concernée. Cette distribution n'est toutefois pas utilisée dans les systèmes de production.


    La porte dérobée ayant été découverte avant que les versions malveillantes de xz Utils ne soient ajoutées aux versions de production de Linux, « elle n'affecte personne dans le monde réel », a déclaré Will Dormann, analyste principal des vulnérabilités au sein de la société de sécurité Analygence. « Mais c'est uniquement parce qu'elle a été découverte rapidement en raison de la négligence d'un acteur malveillant. Si elle n'avait pas été découverte, elle aurait été catastrophique pour le monde entier ».

    Introduction de la porte dérobée

    Le 23 février, une mise à jour a ajouté du code obfusqué, et le jour suivant, un script d’installation malveillant s’est injecté dans les fonctions utilisées par sshd, le fichier binaire qui permet le fonctionnement de SSH. Le code malveillant n’a été présent que dans les versions archivées (connues sous le nom de tarballs), qui sont publiées en amont. Le code GIT disponible dans les référentiels n’est pas affecté, bien qu’il contienne des artefacts de deuxième étape permettant l’injection lors de la construction. Si le code obfusqué introduit le 23 février est présent, les artefacts dans la version GIT permettent à la porte dérobée de fonctionner.

    Les modifications malveillantes ont été soumises par JiaT75, l’un des deux principaux développeurs de xz Utils avec des années de contributions au projet. Andres Freund, le développeur qui a découvert la porte dérobée, a noté que compte tenu de l’activité sur plusieurs semaines, le contributeur est soit directement impliqué, soit son système a été compromis de manière assez sévère. « Malheureusement, cette dernière explication semble la moins probable, étant donné qu'il a communiqué sur diverses listes à propos des "correctifs" fournis dans les récentes mises à jour », a-t-il continué.

    Jeudi, une personne utilisant le nom du développeur s'est rendue sur un site de développeurs pour Ubuntu afin de demander que la version 5.6.1 antidatée soit incorporée dans les versions de production, car elle corrigeait des bogues qui provoquaient le dysfonctionnement d'un outil connu sous le nom de Valgrind.

    « Cela pourrait perturber les scripts de construction et les pipelines de test qui attendent des résultats spécifiques de Valgrind pour réussir », a averti la personne, à partir d'un compte créé le même jour.

    Nom : bug.png
Affichages : 109847
Taille : 25,7 Ko

    L'un des responsables de Fedora a déclaré vendredi que le même développeur l'avait approché ces dernières semaines pour demander que Fedora 40, une version bêta, incorpore l'une des versions d'utilitaires rétroactives.

    « Nous avons même travaillé avec lui pour résoudre le problème de valgrind (qui s'est avéré être causé par la porte dérobée qu'il avait ajoutée) », a déclaré le responsable d'Ubuntu. « Il fait partie du projet xz depuis deux ans, ajoutant toutes sortes de fichiers de test binaires, et avec ce niveau de sophistication, nous nous méfierions des versions plus anciennes de xz jusqu'à preuve du contraire ».

    Selon les chercheurs, les versions malveillantes interfèrent intentionnellement avec l'authentification effectuée par SSH, un protocole couramment utilisé pour se connecter à distance à des systèmes. SSH fournit un chiffrement robuste pour garantir que seules les parties autorisées se connectent à un système distant. La porte dérobée est conçue pour permettre à un acteur malveillant de briser l'authentification et, à partir de là, d'obtenir un accès non autorisé à l'ensemble du système. La porte dérobée fonctionne en injectant du code pendant une phase clé du processus de connexion.

    « Je n'ai pas encore analysé précisément ce qui est vérifié dans le code injecté pour permettre un accès non autorisé », a écrit Freund. « Étant donné que ce code est exécuté dans un contexte de préauthentification, il semble probable qu'il permette une forme d'accès ou une autre forme d'exécution de code à distance ».

    Dans certains cas, la porte dérobée n'a pas pu fonctionner comme prévu. L'environnement de build de Fedora 40, par exemple, contient des incompatibilités qui empêchent l'injection de se produire correctement. Fedora 40 est maintenant revenue aux versions 5.4.x de xz Utils.

    Xz Utils est disponible pour la plupart des distributions Linux, mais toutes ne l'incluent pas par défaut. Toute personne utilisant Linux doit immédiatement vérifier auprès de son distributeur si son système est affecté. Freund a fourni un script permettant de détecter si un système SSH est vulnérable.

    Plusieurs personnes ont signalé que les applications incluses dans le gestionnaire de paquets HomeBrew pour macOS utilisaient la version 5.6.1 de xz Utils avec la porte dérobée. HomeBrew a depuis rétrogradé l’utilitaire à la version 5.4.6.

    Les distributions affectées

    Red Hat a averti vendredi qu'une porte dérobée malveillante découverte dans la bibliothèque logicielle de compression de données xz, largement utilisée, pourrait être présente dans des instances de Fedora Linux 40 et dans Fedora Rawhide, une version de Fedora en perpétuel développement (cette version sert à l'inclusion de technologies émergentes ayant un avenir dans les versions futures et stables de Fedora. Rawhide n'est jamais stable. Deux fois par an, un état « x » de Rawhide est copié en une nouvelle branche parallèle, qui sera quant à elle stabilisée et débogué pour devenir une version stable de Fedora). La grande enseigne de l'informatique a déclaré que le code malveillant, qui semble fournir un accès à distance via OpenSSH et systemd au moins, est présent dans xz 5.6.0 et 5.6.1. La vulnérabilité a été désignée sous le nom de CVE-2024-3094. Elle est notée 10 sur 10 dans la sévérité CVSS.

    Les utilisateurs de Fedora Linux 40 peuvent avoir reçu la version 5.6.0, en fonction de la date de mise à jour de leur système, selon Red Hat. Les utilisateurs de Fedora Rawhide, la version de développement actuelle de ce qui deviendra Fedora Linux 41, pourraient avoir reçu la version 5.6.1. Les versions 40 et 41 de Fedora n'ont pas encore été officiellement publiées ; la version 40 devrait sortir le mois prochain.

    Les utilisateurs d'autres distributions Linux et OS doivent vérifier quelle version de la suite xz ils ont installée. Les versions infectées, 5.6.0 et 5.6.1, ont été publiées respectivement le 24 février et le 9 mars, et n'ont peut-être pas été intégrées dans les déploiements de beaucoup de personnes.

    Cette compromission de la chaîne d'approvisionnement a peut-être été détectée suffisamment tôt pour empêcher une exploitation généralisée, et elle n'affecte peut-être que les distros de pointe qui ont immédiatement récupéré les dernières versions de xz.

    Debian Unstable et Kali Linux ont indiqué qu'elles étaient, comme Fedora, affectées ; tous les utilisateurs devraient prendre des mesures pour identifier et supprimer toutes les versions de xz ayant fait l'objet d'une rétrocession.

    « Veuillez cesser immédiatement d'utiliser toute instance de Fedora Rawhide pour votre travail ou vos activités personnelles », a déclaré la filiale d'IBM. « Fedora Rawhide sera prochainement ramené à la version xz-5.4.x. Une fois cette opération effectuée, les instances Fedora Rawhide pourront être redéployées en toute sécurité ».

    Red Hat Enterprise Linux (RHEL) n'est pas concerné.

    SUSE a publié un correctif pour les utilisateurs d'openSUSE.

    Nom : red.png
Affichages : 30682
Taille : 98,4 Ko

    Le code malveillant dans les versions 5.6.0 et 5.6.1 de xz a été obscurci, selon Red Hat, et n'est présent que dans l'archive du code source. Les artefacts de seconde étape dans le repo Git sont transformés en code malveillant par le biais de la macro M4 dans le repo pendant le processus de construction. La bibliothèque xz empoisonnée qui en résulte est utilisée à son insu par des logiciels, tels que le système d'exploitation systemd, une fois que la bibliothèque a été distribuée et installée. Le logiciel malveillant semble avoir été conçu pour altérer le fonctionnement des démons du serveur OpenSSH qui utilisent la bibliothèque via systemd.

    « La version malveillante qui en résulte interfère avec l'authentification dans sshd via systemd », explique Red Hat. « SSH est un protocole couramment utilisé pour se connecter à distance à des systèmes, et sshd est le service qui permet l'accès ».

    Conclusion

    Cette interférence d'authentification peut permettre à un malfaiteur de rompre l'authentification sshd et d'obtenir à distance un accès non autorisé à un système affecté. En résumé, la porte dérobée semble fonctionner comme suit : Les machines Linux installent la librairie xz - plus précisément, liblzma - et cette dépendance est finalement utilisée d'une manière ou d'une autre par le daemon OpenSSH de l'ordinateur. À ce stade, la bibliothèque xz empoisonnée est en mesure d'interférer avec le démon et de permettre à un malfaiteur non autorisé de se connecter à distance.

    Cette découverte souligne l’importance de la sécurité dans la chaîne d’approvisionnement logicielle et met en évidence les risques potentiels pour les systèmes SSH. Il est essentiel de surveiller de près les mises à jour et de vérifier l’intégrité des outils et des bibliothèques utilisés dans les distributions Linux et autres systèmes d’exploitation.

    Sources : Andres Freund, HomeBrew, Ubuntu, Red Hat CVE-2024-3094, avis de sécurité de Red Hat, SUSE, Debian

    Et vous ?

    Quelle est votre opinion sur la sécurité dans la chaîne d’approvisionnement logicielle ? Pensez-vous que les développeurs et les mainteneurs de logiciels devraient être plus vigilants lorsqu’ils intègrent des mises à jour ou des bibliothèques tierces ?
    Comment cela pourrait-il affecter la confiance des utilisateurs envers les distributions Linux et les outils open source ? La découverte de cette porte dérobée pourrait-elle entraîner une méfiance accrue envers les logiciels open source ? Comment les projets open source peuvent-ils renforcer la confiance des utilisateurs ?
    Quelles mesures de sécurité supplémentaires devraient être mises en place pour détecter et prévenir de telles menaces ? Comment pouvons-nous améliorer la détection précoce des portes dérobées et des vulnérabilités dans les logiciels largement utilisés ?
    Quel rôle les entreprises et les organisations jouent-elles dans la vérification de la sécurité des logiciels qu’elles utilisent ? Devraient-elles investir davantage dans des audits de sécurité indépendants pour s’assurer que les outils qu’elles utilisent sont exempts de portes dérobées ?
    Comment pouvons-nous sensibiliser davantage les utilisateurs et les développeurs à l’importance de la sécurité logicielle ? Quelles initiatives éducatives ou de sensibilisation pourraient aider à prévenir de telles situations à l’avenir ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre extrêmement actif
    Profil pro
    Analyste cogniticien
    Inscrit en
    Novembre 2010
    Messages
    270
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Analyste cogniticien

    Informations forums :
    Inscription : Novembre 2010
    Messages : 270
    Points : 629
    Points
    629
    Par défaut
    C'est vraiment méchant de faire ça. J'espère que ce mainteneur sera traduit en justice.

  3. #3
    Membre du Club
    Homme Profil pro
    Collégien
    Inscrit en
    Novembre 2020
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Collégien

    Informations forums :
    Inscription : Novembre 2020
    Messages : 14
    Points : 51
    Points
    51
    Par défaut
    Une IA qui contrôle les ajouts est expressément demandée.
    Il y a plein de développement sur des IA idiotes, pour la sécurité personne même pas Apple (zut c'est pourtant leur priorité selon leur marketing agressif)

  4. #4
    Expert éminent Avatar de kain_tn
    Homme Profil pro
    Inscrit en
    Mars 2005
    Messages
    1 564
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations forums :
    Inscription : Mars 2005
    Messages : 1 564
    Points : 7 285
    Points
    7 285
    Par défaut
    Bon, pour Debian, on parle de la unstable et de la testing - c'est-à-dire des versions qui ne sont en principe utilisées que par les mainteneurs de paquets (aujourd'hui, avec les containeurs, le besoin de passer sur une version testing est assez faible, je trouve).

    De plus, ils disent que l'exploitation se fait via systemd.

    En stable (c'est-à-dire sur les serveurs de production ainsi que pour les utilisateurs normaux), on est bien en dessous de la version impactée. Et si en plus on tourne avec init ou openrc, plutôt qu'avec cette usine à bugs qu'est systemd, alors là...

    Kali, c'est utilisé pour le pentesting. Ce n'est pas non-plus une distribution que l'on va utiliser pour le quotidien. À tout hasard, j'ai regardé sur ma Kali, et je vois que xz-utils est en version 5.4 - c'est-à-dire que la distribution de base n'est absolument pas affectée.

    Citation Envoyé par Stéphane le calme Voir le message
    Quelle est votre opinion sur la sécurité dans la chaîne d’approvisionnement logicielle ? Pensez-vous que les développeurs et les mainteneurs de logiciels devraient être plus vigilants lorsqu’ils intègrent des mises à jour ou des bibliothèques tierces ?
    La chaîne d'approvisionnement logicielle est vitale (on le voit assez souvent - SolarWinds, quelqu'un?).

    Et aujourd'hui, avec les IA génératives à toutes les sauces, il y a de plus en plus de chances d'avoir des feignasses qui importent n'importe quel package suggéré par de l'iA au sein de "leur" code.

    Citation Envoyé par Stéphane le calme Voir le message
    Comment cela pourrait-il affecter la confiance des utilisateurs envers les distributions Linux et les outils open source ? La découverte de cette porte dérobée pourrait-elle entraîner une méfiance accrue envers les logiciels open source ? Comment les projets open source peuvent-ils renforcer la confiance des utilisateurs ?
    Bon, il faut arrêter de se leurrer: du spyware, il y en a plein les logiciels. Il y a suffisamment d'articles sur le sujet. La différence, c'est que pour de l'open source, une entreprise ou un état a les moyens de vérifier. Mais c'est comme tout, ça coûte du temps et donc de l'argent.

    Citation Envoyé par Stéphane le calme Voir le message
    Quel rôle les entreprises et les organisations jouent-elles dans la vérification de la sécurité des logiciels qu’elles utilisent ? Devraient-elles investir davantage dans des audits de sécurité indépendants pour s’assurer que les outils qu’elles utilisent sont exempts de portes dérobées ?
    Elles ont clairement un rôle à jouer, oui. Open-Source, ça ne veut pas dire gratuit.

    Citation Envoyé par Stéphane le calme Voir le message
    Comment pouvons-nous sensibiliser davantage les utilisateurs et les développeurs à l’importance de la sécurité logicielle ? Quelles initiatives éducatives ou de sensibilisation pourraient aider à prévenir de telles situations à l’avenir ?
    La sécurité, c'est le parent pauvre du développement. On cherche toujours à baisser les coûts de développements. On suggère que des IA génératives peuvent faire le travail. On préfère payer une misère des personnes inexpérimentées formées en bootcamp, plutôt que des développeurs expérimentés. On laisse peu de temps aux projets. Au bout d'un moment, ça se paye en bugs et en vulnérabilités.
    Copier c'est copier; voler c'est vendre un CD une vingtaine d'euros!


    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    #include <stdio.h>
     
    int main(int argc, char **argv) {
     
        printf("So long, and thanks for the fish, Dennis...\n");
        return 0;
    }

  5. #5
    Expert confirmé Avatar de sergio_is_back
    Homme Profil pro
    Responsable informatique, développeur tout-terrain
    Inscrit en
    Juin 2004
    Messages
    1 083
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Responsable informatique, développeur tout-terrain
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 083
    Points : 5 593
    Points
    5 593
    Par défaut
    Citation Envoyé par kain_tn Voir le message
    La sécurité, c'est le parent pauvre du développement. On cherche toujours à baisser les coûts de développements. On suggère que des IA génératives peuvent faire le travail. On préfère payer une misère des personnes inexpérimentées formées en bootcamp, plutôt que des développeurs expérimentés. On laisse peu de temps aux projets. Au bout d'un moment, ça se paye en bugs et en vulnérabilités.
    On est sur un cas un peu différent là : La porte dérobée a été introduite à dessein, le code obscurcit pour masquer sa présence. Donc tout semble indiquer que cela a été fait sciemment pour introduire une vulnérabilité difficilement détectable du premier coup d’œil, c'est pas un développeur inexpérimenté, c'est un acte conscient et malveillant.

  6. #6
    Expert éminent Avatar de kain_tn
    Homme Profil pro
    Inscrit en
    Mars 2005
    Messages
    1 564
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations forums :
    Inscription : Mars 2005
    Messages : 1 564
    Points : 7 285
    Points
    7 285
    Par défaut
    Citation Envoyé par sergio_is_back Voir le message
    On est sur un cas un peu différent là : La porte dérobée a été introduite à dessein, le code obscurcit pour masquer sa présence. Donc tout semble indiquer que cela a été fait sciemment pour introduire une vulnérabilité difficilement détectable du premier coup d’œil, c'est pas un développeur inexpérimenté, c'est un acte conscient et malveillant.
    Je répondais sur la phrase "Comment pouvons-nous sensibiliser davantage les utilisateurs et les développeurs à l’importance de la sécurité logicielle ?", mais tu as raison.
    Copier c'est copier; voler c'est vendre un CD une vingtaine d'euros!


    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    #include <stdio.h>
     
    int main(int argc, char **argv) {
     
        printf("So long, and thanks for the fish, Dennis...\n");
        return 0;
    }

Discussions similaires

  1. Réponses: 6
    Dernier message: 08/06/2023, 13h42
  2. [VB6] Ouverture d'une nouvelle fenêtre dans un MDI
    Par pepper dans le forum VB 6 et antérieur
    Réponses: 8
    Dernier message: 17/02/2003, 14h03
  3. problème xsl : inclure une donnée xml dans une balise html
    Par djodjo dans le forum XSL/XSLT/XPATH
    Réponses: 3
    Dernier message: 03/01/2003, 09h24
  4. comment integer une animation swf dans une page
    Par naili dans le forum Intégration
    Réponses: 7
    Dernier message: 18/09/2002, 18h54
  5. Copier une image (jpeg) dans le presse papier
    Par benj63 dans le forum C++Builder
    Réponses: 2
    Dernier message: 29/07/2002, 14h51

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo