Journal Une vulnérabilité sans patch possible…

Posté par  . Licence CC By‑SA.
Étiquettes :
5
17
mai
2021

Bonjour Nal,

Si tu as une machine de Turing universelle qui tourne dans un coin, fais gaffe: un 0-day a été découvert, qui permet une exécution de code arbitraire!

Pire, il semble qu'il n'y ait aucun moyen de s'en protéger.

Cette faille a été vérifiée sur l'implémentation faite par Marvin Minsky en 1967, mais je pense que toutes les implémentations sont vulnérables.

Tout ça est expliqué dans un article sur ArXiv.

Bien évidemment, la faille a été répertoriée par MITRE et s'est vu attribuer un petit nom : CVE-2021-32471.

  • # Bof

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

    En gros ça dit que si ta machine de Turing oublie de prévoir le cas où une input pas prévue arrive, on peut en faire n'importe quoi. Genre "la machine ne prend que des 0 et des 1, si tu lui met un 2, qui sert de code de controle, en donnée, tu peux l'exploiter".

    Effectivement, il faut changer la machine dans ce cas pour colmater la faille. Mais sinon, dans la vraie vie, tu mettra pas un 2 dans un bit, même avec toute la bonne volonté. Donc voilà quoi.

    • [^] # Re: Bof

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

      NOTE: the discoverer states "this vulnerability has no real-world implications."

      Comme c'est dit dans le CVE

    • [^] # Re: Bof

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

      C'est une preuve de concept.

      Ta conclusion est erronée par rapport à ce qui est démontré, qui est : en pratique, l'utilisateur d'un "programme" entrera quelque chose d'inattendu. Et cet utilisateur, ce n'est pas toi. Donc s'il veut rentrer un 2, si tu lui en laisse la possibilité, il le ferra (volontairement ou non).

  • # calcul de Pi dans Star Trek

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

    C'est un peu comme dans l'épisode de Star Trek (Wolf in the Fold) dans lequel Spock "flingue" l'ordinateur central devenu fou en lui demandant de calculer Pi jusqu'à la dernière décimale.

    https://www.inverse.com/article/29052-pi-day-3-14-2018-spock-star-trek

    • [^] # Re: calcul de Pi dans Star Trek

      Posté par  (site Web personnel) . Évalué à 10 (+10/-2). Dernière modification le 17/05/21 à 15:30.

      Aujourd'hui l'ordinateur lui répondrait:
      ```
      NaN dsl

      Voulez-vous reporter ce problème via notre service de télémétrie ? [Acceptez tout,refusez tout,lire les 666 pages des conditions générales de vente et cocher la liste de 42 trackers pour chacun de nos 33 partenaires]
      ```

      Si vous trouvez ce post offensant, je m'en excuse. Prévenez moi sur sur https://linuxfr.org/board/

  • # "sans patch possible"

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

    "sans patch possible", vraiment? L'article dit exactement le contraire et propose deux façons de corriger l'implémentation (c'est pas difficile à trouver, c'est le chapitre "Mitigations"):

    1) Valider les entrées, en particulier vérifier qu'il n'y a que des 1 et des 0 dedans (la machine représente chaque case par un octet et utilise en interne d'autres valeurs "A" et "B", et ne vérifie pas avant de démarrer l'exécution que le programme ne contient pas autre chose que des 1 et des 0)

    2) Spécifier complètement la machine, en gros dans le code il y a des tests du genre if (valeur == 0) { … } else { … } sous-entendant que le else s'exécute pour valeur == 1, mais en fait il s'exécute aussi pour "A" et "B". Donc on peut réécrire le code: if (valeur == 0) { … } else if (valeur == 1) { … } else { erreur }

    Les problèmes ne sont pas dans l'idée même d'une machine de Turing universelle, mais bien dans cette implémentation spécifique. Implémentation dont le but était, non pas d'être sécurisée, mais d'être le plus simple possible.

    • [^] # Re: "sans patch possible"

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

      De ce que je comprend, le problème n'est même pas dans le machine de Turing elle-même mais dans le programme qu'elle exécute. Pour une mitigation au niveau « machine », c'est plutôt du côté d'une séparation entre données et code qu'il faudrait creuser.

      Mais ouais, mieux vaut lire l'article que les journaux et commentaires DLFP qui l'interprètent.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: "sans patch possible"

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

        Je n'avais pas la prétention d'interpréter mais de faire sourire, je m'étonne d'avoir été pris si au sérieux, l'humour n'est pourtant pas rare sur LinuxFr.

        Et oui, je le reconnais ci-dessous, je n'avais pas lu jusqu'au bout.

        Ceci dit, quand tu sépares machine et programme, une machine de Turing universelle n'est-elle pas supposée pouvoir simuler toute machine de Turing? ;-)

        • [^] # Re: "sans patch possible"

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

          Oui, j'imagine qu'il est possible d'implémenter une architecture de Harvard (par opposition à l'architecture de von Neumann) sur une machine de Turing. Et les programmes que tu fera tourner sur cette VM seront sans doute moins vulnérable à certaines de ces attaques.

          https://en.wikipedia.org/wiki/Harvard_architecture

          Au final je vois ce papier comme un rappel qu'il est approximativement impossible d'écrire du code sans bug, ce que je vois comme une application du problème de l'arrêt.

          Mais encore une fois, mieux vaut lire Wikipedia que mon commentaire :)

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: "sans patch possible"

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

            L'article parle également de l'architecture de Harvard avec plusieurs arguments qui expliquent pourquoi ça ne suffit pas:

            • D'abord, l'architecture de Harvard "pure" ne permet pas de charger du code arbitraire (puisque la mémoire programme est en lecture seule), et donc, ça limite les possibilités.
            • Un contournement de cette limitation est possible: ajouter une instruction qui permet d'écrire dans la mémoire programme, mais dans ce cas l'instruction en question peut également être exploitée pour injecter du code, et donc on a rien gagné,
            • Sur les ordinateurs récents, il n'est pas rare d'avoir du code interprété (scripts bash, python, javascript, ou tout simplement exécution de commandes sur un prompt shell) et cela pourrait être exploité également,
            • Enfin, il existe des attaques dans lesquelles il n'y a pas à proprement parler d'injection de code. Par exemple le "return oriented programming" qui consiste à appeler des petits bouts de code existants et à les enchaîner de façon à faire ce qu'on veut.

            En pratique, sur les ordinateurs modernes, on est pas loin d'avoir une architecture de Harvard, avec la MMU qui peut indiquer quelles zones de la mémoire peuvent être écrites et quelles zones peuvent être exécutées (en principe ce ne sont pas les mêmes). C'est apparu sur les processeurs x86 en 2003 par exemple: https://fr.wikipedia.org/wiki/NX_Bit et on peut pas vraiment dire que ça a bouché d'un coup toutes les failles, même si ça a sûrement rendu le travail des vilains pirates un peu plus difficile.

            • [^] # Re: "sans patch possible"

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

              Enfin, il existe des attaques dans lesquelles il n'y a pas à proprement parler d'injection de code. Par exemple le "return oriented programming" qui consiste à appeler des petits bouts de code existants et à les enchaîner de façon à faire ce qu'on veut.

              Je ne sais pas pourquoi j'ai pensé aux tuyaux unixiens…

    • [^] # Re: "sans patch possible"

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

      Ça m'apprendra à lire jusqu'au bout, merci.

      Ceci dit, mon journal était plutôt destiné à faire sourire qu'à être pris au sérieux, ça m'a notamment bien amusé que la "faille" soit répertoriée avec une entrée CVE alors que –comme dit dans l'article et dans un commentaire plus haut– il n'y a pas de conséquence dans le monde réel…

  • # Test de Gnirut

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

    Récemment un client a appellé furibard car il tentait de se loguer sur un service, en était à son 15eme capcha, et était toujours dehors.

    On lui a donc annoncé la triste nouvelle : vous avez échoué au test de Gnirut ; La machine vous a clairement identifié comme un humain :)

Envoyer un commentaire

Suivre le flux des commentaires

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