• # Pas de solution ?

    Posté par  . Évalué à 6 (+4/-0).

    Comme le dit la présentation, ça marche dans VSCode, mais ça marche plutôt dans un éditeur qui tente d'analyser un dépôt en profondeur.

    C'est quand même assez incroyable de pouvoir lire des fichiers en dehors de la racine du projet, et d'ouvrir des connexions TCP dans une macro. Je sais que c'est sûrement « pratique », mais bon, ça ne pouvait que mal se passer.

    • [^] # Re: Pas de solution ?

      Posté par  . Évalué à 5 (+5/-0).

      La methode est originale, mais je dirais: rien de bien nouveau.

      Si je prends CMake, un upload de fichier peut-etre cachė au milieu du script de build: https://cmake.org/cmake/help/latest/command/file.html

      Pas mal de projets peuvent inclure des helpers python pour le build, …

      Les tests unitaires peuvent executer absolument n'importe quoi, …

      Donc, oui, on doit avoir confiance dans le code que l'on importe ou l'executer dans une sandbox.

      Mwha

    • [^] # Re: Pas de solution ?

      Posté par  . Évalué à 5 (+3/-0). Dernière modification le 15/05/21 à 20:44.

      D'après ce que j'ai pu comprendre, c'est un peu plus fourbe que ça. Les macros peuvent faire ce qu'elles veulent, comme par exemple générer des structures.

      Donc pour faire de la résolution correcte, il est nécessaire d'executer certaines macros. Or, elles peuvent aussi ouvrir des connexions (pour récupérer un wdsl par exemple) et lire des fichiers.

      Bref, envoyer les clés ssh de l'utilisateur à la lecture du code du projet, ça va vite…

      Je suppose que l'outil principal pour faire de l'analyse via language server protocol, rust analyzer, est celui qui est "fautif" dans ce cas-ci.
      Donc, vim, emacs, et autres qui reposent sur lui sont aussi vulnérables.

      Une solution consisterait à exécuter rust-analyzer dans un container avec ce dont il a besoin. Il me semble que pour vscode, c'est en cours de dev.

      Maintenant, il n'est pas impossible que d'autres langages soient impactés (java par exemple)

      • [^] # Re: Pas de solution ?

        Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

        C'est possible avec Java et certains IDE comme IntelliJ ont implémenté un mode de pnévisualisation qui permet de charger un projet sans exécuter les scripts de build / de récupération de dépendances Maven ou Gradle qui peuvent contenir du code malveillant.

        La connaissance libre : https://zestedesavoir.com

        • [^] # Re: Pas de solution ?

          Posté par  . Évalué à 2 (+0/-0).

          Je trouve dommage que ce soit fait à l'ouverture, je pense que ce serait bien que ce soit fait via un truc non bloquant pour pouvoir regarder le code puis accepter (ou non).

          • [^] # Re: Pas de solution ?

            Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

            C'est exactement ça en fait. Tu peux ouvrir ton code de façon sécurisée pour pouvoir le regarder et basculer en mode édition quand tu as vérifié que tout est OK.

            La connaissance libre : https://zestedesavoir.com

            • [^] # Re: Pas de solution ?

              Posté par  . Évalué à 2 (+0/-0).

              Ah je n'ai pas assez essayé alors. Il me semblait qu'il m'avait demandé ça via une popup dès l'ouverture.

      • [^] # Re: Pas de solution ?

        Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

        J'utilise vim avec youcompleteme et la première chose qu'il fait avant de charger quoi que ce soit, c'est de me dire qu'il a détecté une config d'autocomplétion dans le projet et de me demander si je veux la charger. Si je dis non, la complétion intelligente et l'analyse de syntaxe sont désactivées.

        Je peux également faire une liste verte des dossiers qui sont autorisés (dans laquelle je met mes projets "sûrs" pour ne pas avoir à répondre à la question chaque fois que j'ouvre un éditeur)

        • [^] # Re: Pas de solution ?

          Posté par  . Évalué à 2 (+0/-0).

          Pour emails, il semble qu'il existe une solution a base de container : https://github.com/emacs-lsp/lsp-docker

          Par contre, je ne vois pas de référence à rust, mais je suppose qu'un peu de configuration doit être suffisant.

        • [^] # Re: Pas de solution ?

          Posté par  . Évalué à 3 (+1/-0).

          Je peux également faire une liste verte des dossiers qui sont autorisés (dans laquelle je met mes projets "sûrs" pour ne pas avoir à répondre à la question chaque fois que j'ouvre un éditeur)

          Attention aux PR/MR vérolées ;)

      • [^] # Re: Pas de solution ?

        Posté par  . Évalué à 2 (+0/-0).

        Maintenant, il n'est pas impossible que d'autres langages soient impactés (java par exemple)

        Quelque soit le langage l'outil de build peut faire ce qu'il veut et le code lui même si tu as l'intention de l'exécuter un jour.

    • [^] # Re: Pas de solution ?

      Posté par  . Évalué à 2 (+1/-0).

      Ben si, la solution c'est de pas avoir accès à Internet depuis ta machine de dev (ou ton réseau de prod).

      Ça peut faire sourire, mais c'est une des exigence de certains de nos clients. Les techniques du genre Remote Browser Isolation¹ sont une bonne solution pour pouvoir consulter le web tout en n'ayant pas d'accès à Internet.


      ¹ La plupart du temps, ça consiste à envoyer les infos clavier/souris dans un navigateur qui est dans une DMZ et à récupérer les pixels de l'affichage.

      • [^] # Re: Pas de solution ?

        Posté par  . Évalué à 3 (+1/-0).

        Ben si, la solution c'est de pas avoir accès à Internet depuis ta machine de dev (ou ton réseau de prod).

        Ça n'empêche pas un ransomware de chiffrer tes données et de te demander une rançon.

        • [^] # Re: Pas de solution ?

          Posté par  . Évalué à 1 (+0/-0).

          Certes, si ransomware passe par un autre vecteur d'infection.

          Note que ça n'empêche pas non plus un voleur de te piquer ton ordi chez toi, ou encore une culturiste de broyer ton ordi à mains nues, juste pour le plaisir :).

          • [^] # Re: Pas de solution ?

            Posté par  . Évalué à 4 (+2/-0). Dernière modification le 18/05/21 à 21:59.

            En fait quand tu prend du code sur internet et que tu l'ouvre avec ton outil favori, tu exécute du code arbitraire, que ce soit via une macro rust, l'outil de build ou le code lui même cela pose un risque.

            Oui, il fait l'auditer, mais d'une part est-ce que l'on sait auditer la sécurité de n'importe quel code ? D'autre part pour cela il faut que l'outil que tu utilise pour le le code ne se fasse pas déjà trouer par la lecture (comme avec la coloration syntaxique par exemple, mais ce n'est qu'une option).

            Il faut bien se rendre compte que récupérer du code et le lire sur son ordinateur et la base de la collaboration des projets communautaires. Donc potentiellement des gens qui ne sont pas professionnels ou qui n'y passent pas 8h/jour et qui n'ont pas d'équipes de DSI ni même d'infrastructures pour dédier une machine à chaque tâche.

            • [^] # Re: Pas de solution ?

              Posté par  . Évalué à 2 (+0/-0).

              On peut éventuellement rajouter les squats de typographie, disponibles dans tout gestionnaire de paquets un tant soit peu populaire ;)

  • # ms word

    Posté par  . Évalué à 1 (+0/-0).

    En fait, tout ça me rappelle le problème des macros dans Word des années 90.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.