• # Intéressant !

    Posté par  (site web personnel) . Évalué à 6 (+3/-0).

    C'est intéressant de voir que ces bugs sont issues de l'ergonomie des API qui ne tiennent pas compte de ces patterns dangereux (ex: check et action séparé dans le temps pour les fichiers).

    "La première sécurité est la liberté"

    • [^] # Re: Intéressant !

      Posté par  (site web personnel) . Évalué à 10 (+11/-0).

      C'est aussi marrant de voir que réécrire une suite logicielle (coreutils -> uutils) qui a plusieurs décennies de bugfix ait comme conséquence de reproduire ces bugs.

      Mon préféré:

      • coreutils: kill -1 envoit le signal 1 à un PID que l'on va demander à l'utilisateur
      • uutils: kill -1 envoit le signal par défaut à tout les PIDs (car PID -1 sur Linux c'est tout les PIDs)

      Sous prétexte que "C n'est pas sécurisé" :(

      https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

      • [^] # Re: Intéressant !

        Posté par  (site web personnel) . Évalué à 4 (+4/-3).

        Oui mais 20 ans après, il y a toujours des CVE sur coreutils. Dans les CVE rust, il n'y a pas de buffer overflow ou autre double free.

        "La première sécurité est la liberté"

        • [^] # Re: Intéressant !

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

          Il me semble, mais je me trompe peut-être, que les CVEs listées pour uutils sont bien plus facile à exploiter qu'un buffer overflow dans pwd.

          Des CVEs il y en aura toujours, et plus il y aura de code écrit en Rust, par plus de développeur, plus on trouvera de CVE dans les implémentations en Rust.

          Alors oui, la nature des CVEs change. Mais les problèmes de mémoires en C ne pourraient-ils pas être détecté avec de meilleurs tests (usage de ASan / UBSan, fuzzing, …) ?

          Par exemple, l'article cite comme bug absent de l'implémentation Rust:

          No data races on shared mutable state.

          Pour coreutils spécifiquement, qui est un ensemble de programmes "single threaded", est-ce pertinent ?

          No use after free, no double free

          Une grande partie des programmes de coreutils n'ont même pas besoin de faire d'allocation dynamique.

          https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

          • [^] # Re: Intéressant !

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

            Il me semble, mais je me trompe peut-être, que les CVEs listées pour uutils sont bien plus facile à exploiter qu'un buffer overflow dans pwd.

            Justement je n'en suis pas convaincu pour une bonne part d'entre eux. Beaucoup de choses demandent d'agir dans une fenêtre temporelle faible pour les exploiter.

            Mais les problèmes de mémoires en C ne pourraient-ils pas être détecté avec de meilleurs tests (usage de ASan / UBSan, fuzzing, …) ?

            Cela aide mais est rarement suffisant. Je doute que les développeurs de coreutils n'aient jamais employés ces techniques.

            En fait Rust réduit les problèmes en invalidant pas mal de programme en théorie valide mais risqué, et malgré tout l'outillage du C, tu dois composer avec ses limitations intrinsèques à cause d'une forte permissivité.

            Pour coreutils spécifiquement, qui est un ensemble de programmes "single threaded", est-ce pertinent ?

            Déjà je ne pense pas que ce soit vrai pour tous, d'ailleurs sort() fait un appel explicite à pthread. Et il n'y a pas de raisons que d'autres ne puissent pas être parallélisées selon les cas pour des opérations un peu lourde (genre quand les actions sont récursives).

            L'usage du C peut être un frein à ce genre d'évolutions.

            Une grande partie des programmes de coreutils n'ont même pas besoin de faire d'allocation dynamique.

            Mais une bonne partie en a besoin.

            Je pense que cette réécriture a plusieurs effets bénéfiques, un peu comme Clang vis à vis de GCC :

            • Cela force à devoir améliorer la documentation si des informations importantes n'étaient pas explicites
            • Cela force a décrire l'interface réelle de ces programmes, et d'associer cela à des tests pour s'assurer la compatibilité
            • Cela peut pousser coreutils à évoluer si par exemple les performances sont moins bonnes que la version Rust
            • Etc.

      • [^] # Re: Intéressant !

        Posté par  (site web personnel) . Évalué à 2 (+2/-3).

        Le bug ici c'est pas plutôt une convention de passage de paramètres conçue avec le cul ?

        Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board

Envoyer un commentaire

Suivre le flux des commentaires

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