Comment éviter les attaques de séquence d'échappement dans les terminaux?

En lisant les détails de CVE-2009-4487 (qui concerne le danger des séquences d'échappement dans les fichiers journaux), je suis un peu surpris.

Pour citer CVE-2009-4487 :

nginx 0.7.64 écrit des données dans un fichier journal sans nettoyer les caractères non imprimables, ce qui pourrait permettre à des attaquants distants de modifier le titre d'une fenêtre, ou éventuellement d'exécuter des commandes arbitraires ou d'écraser des fichiers, via une requête HTTP contenant une séquence d'échappement pour un émulateur de terminal.

De toute évidence, il ne s'agit pas vraiment d'une faille de sécurité dans nginx, mais dans les émulateurs de terminaux.

Bien sûr, peut-être catqu'ingérer un fichier journal sur le terminal ne se produit que par accident, mais greping un fichier journal est assez courant. lesspeut-être désinfecte les séquences d'échappement, mais qui sait quelles commandes shell ne modifient pas les séquences d'échappement ...

J'ai tendance à être d'accord avec la réponse de Varnish :

La sagesse des échappées de réponse terminale en général a été remise en question à intervalles réguliers, mais aucun des principaux programmes d'émulation de terminal n'a jugé bon de rejeter ces séquences, probablement dans une tentative malencontreuse de compatibilité avec la technologie des années 1970 qui n'est plus utilisée. [..] Au lieu de blâmer tous les programmes qui écrivent des fichiers journaux, il serait beaucoup plus productif, d'un point de vue de la sécurité, de faire en sorte que les programmes d'émulation de terminal cessent de faire des choses stupides, et ainsi de résoudre ce problème et d'autres problèmes de sécurité une fois et pour tous.

Ainsi mes questions:

Comment puis-je sécuriser mon xterm, de sorte qu'il n'est plus possible d'exécuter des commandes ou d'écraser des fichiers via des séquences d'échappement?

Quels émulateurs de terminaux pour X sont protégés contre cette attaque?

Les terminaux VT100 (que tous les émulateurs de terminaux modernes émulent dans une certaine mesure) prenaient en charge un certain nombre de commandes problématiques, mais les émulateurs ou distributions modernes désactivent les plus problématiques et les moins utiles. Voici une liste non exhaustive de séquences d'échappement potentiellement risquées (sans inclure celles qui rendent simplement l'affichage illisible d'une manière ou d'une autre):

• Les commandes de fichiers journaux arbitraires dans rxvt et Eterm rapportées par HD Moore . Ce sont en effet des bugs majeurs, heureusement résolus depuis longtemps.
• La commande de réponse, également appelée Return Terminal Status, invoquée par ENQ( Ctrl+E). Cela insère du texte dans le terminal comme si l'utilisateur l'avait tapé. Cependant, ce texte n'est pas sous le contrôle de l'attaquant: c'est le propre nom du terminal, typiquement quelque chose comme xtermou screen. Sur mon système (Debian squeeze), xterm retourne la chaîne vide par défaut (ceci est contrôlé par la answerbackStringressource).
• Les commandes Send Device Attributes ESC [ cet amis. Le terminal répond par ESC [ … c(où le …peut contenir des chiffres et des signes de ponctuation ASCII uniquement). C'est une façon d'interroger certaines capacités de terminaux, pour la plupart obsolètes mais peut-être utilisées par les anciennes applications. Encore une fois, la réponse du terminal ne se distingue pas de la saisie de l'utilisateur, mais elle n'est pas sous le contrôle de l'attaquant. La séquence de contrôle peut ressembler à une touche de fonction, mais uniquement si l'utilisateur a une configuration inhabituelle (aucun des paramètres habituels que j'ai rencontrés n'a une séquence d'échappement de touche de fonction valide qui est un préfixe de la réponse du terminal).
• Les différentes fonctions de contrôle des appareils (DCS s'échappe, en commençant par ESC P).
  • Je ne sais pas quel dommage peut être fait par DECUDK(définir des clés définies par l' utilisateur) sur un émulateur de terminal typique.
  • DECRQSS(Request Status String) est une autre commande à laquelle le terminal répond avec une séquence d'échappement, commençant cette fois par \eP; cela peut être problématique car \ePc'est une clé valide ( Alt+ Shift+ P).
  • Xterm a deux autres fonctionnalités expérimentales: ESC P + p …et ESC P + q …, pour obtenir et définir des chaînes termcap. D'après la description, cela pourrait être utilisé au moins pour modifier l'effet des touches de fonction.
• Plusieurs commandes de rapport d'état: ESC [ … n(Rapport d'état du périphérique). Le terminal répond avec une séquence d'échappement. La plupart de ces séquences d'échappement ne correspondent pas aux séquences d'échappement des touches de fonction. L'un semble problématique: le rapport ESC [ 6 nest de la forme où et sont des séquences de chiffres, et cela pourrait ressembler à certains modificateurs.ESC [ x ; y RxyF3
• Commandes de manipulation de fenêtres ESC [ … t.
  • Certains d'entre eux permettent de redimensionner, iconifier, etc. la fenêtre xterm, ce qui est perturbateur.
  • Dans certains cas, le terminal répond par une séquence d'échappement. La plupart de ces séquences d'échappement semblent à faible risque, mais il existe deux commandes dangereuses: les réponses à ESC [ 2 0 tet ESC [ 2 1 tincluent respectivement le libellé et le titre de l'icône de la fenêtre du terminal, et l'attaquant peut les choisir.
  • Au moins sous Debian Squeeze, xterm ignore ces commandes par défaut; ils peuvent être activés en définissant la allowWindowOpsressource ou de manière sélective via la disallowedWindowOpsressource. Gnome-terminal sous Ubuntu 10.04 implémente même les réponses de titre par défaut. Je n'ai pas vérifié d'autres terminaux ou versions.
• Commandes pour définir le titre du terminal ou le nom de l'icône. Sous xterm et la plupart des autres terminaux X, ils le sont . Sous écran, la séquence d'échappement est . Je trouve que l'inquiétude suscitée par ces commandes est surfaite. Bien qu'ils autorisent une certaine quantité de méfaits, toute page Web a le même problème. Agir sur une fenêtre basée uniquement sur son titre et non sur sa classe revient à ouvrir un fichier dont le nom vous a été donné par une partie non fiable, à ne pas citer une extension variable dans un script shell ou à caresser un chien enragé sur le nez - ne vous plaignez pas si vous vous faites mordre.ESC ] digit ; title ESC \ESC k title ESC \

Je trouve la réponse de Varnish malhonnête. On dirait que c'est soit en essayant de déplacer le blâme, soit en mode nazi de sécurité (tout problème de sécurité, authentique ou non, justifie le blackballage d'une fonctionnalité).

La sagesse des échappées de réponse terminale en général a été remise en question à intervalles réguliers, mais aucun des principaux programmes d'émulation de terminal n'a jugé bon de rejeter ces séquences, probablement dans une tentative malencontreuse de compatibilité avec la technologie des années 1970 qui n'est plus utilisée. (…)
Au lieu de blâmer tous les programmes qui écrivent des fichiers journaux, il serait beaucoup plus productif, d'un point de vue de la sécurité, de faire en sorte que les programmes d'émulation de terminal cessent de faire des choses stupides, et ainsi de résoudre ce problème et d'autres problèmes de sécurité une fois et pour tous.

Beaucoup de réponses sont des fonctionnalités utiles: une application a besoin de connaître des choses comme la position du curseur et la taille de la fenêtre. La définition du titre de la fenêtre est également très utile. Il serait possible de s'appuyer entièrement sur les ioctlappels pour ces derniers, mais cela aurait nécessité du code et des utilitaires supplémentaires pour effectuer ces ioctlappels et les convertir en texte de style Unix en passant sur les descripteurs de fichiers. Changer ces interfaces maintenant serait beaucoup de travail, pour peu d'avantages.

Les fichiers texte ne sont pas censés contenir des caractères non imprimables tels que des caractères de contrôle. Les fichiers journaux sont généralement censés être des fichiers texte. Les fichiers journaux ne doivent pas contenir de caractères de contrôle.

Si vous craignez qu'un fichier peut contenir des séquences d'échappement, l' ouvrir dans un éditeur, ou voir avec lesssans -rou -R, ou option d' affichage à travers cat -v.

Ce n'est pas aussi simple que cela; beaucoup de gens ont du code pour définir le xtermtitre dans le cadre de l'invite ou etc., et pour de très bonnes raisons (comme toute personne qui se shutdowntrompe de machine depuis la mauvaise fenêtre de terminal peut vous le dire!). Le corriger correctement implique donc d'introduire des contextes de sécurité et donc de compliquer sérieusement l'interaction entre les shells et les émulateurs de terminaux et probablement les fichiers de points des personnes également. Ou vous pouvez opter pour la solution à faible loyer de désinfection de tout ce qui pourrait être affiché dans un terminal; cela se réduit largement à l'échappement des caractères de contrôle, ce qui devrait probablement être fait de toute façon juste pour les faire ressortir (car dans un fichier journal, ils peuvent indiquer quelqu'un essayant d'injecter du shellcode).

(En passant , punycode est un exemple plus grave du même type de problème - et a néanmoins été fait une norme officielle. Parfois, la sécurité se résume à atténuer les conceptions non sécurisées qui échappent à son contrôle.)