Est-il sécuritaire de chatter un fichier arbitraire?

Parfois, lorsque j’ai catun fichier binaire par erreur, mon terminal est déformé. Rien de plus simple resetne peut réparer, mais un attaquant ne pourrait-il théoriquement pas créer un fichier qui, lorsqu'il est affiché sur un terminal, exécuterait du code arbitraire? Par un exploit dans l'émulateur de terminal ou autrement.

L'exploitation de cette sortie dépend du programme du terminal et de ce que ce terminal fait en fonction des codes d'échappement envoyés. Je ne suis pas au courant de programmes de terminal ayant de telles fonctionnalités exploitables, et le seul problème serait maintenant s'il y avait un débordement de mémoire tampon inconnu ou quelque chose du genre, qui pourrait être exploité.

Avec certains hardwareterminaux plus anciens , cela peut poser problème en programmant, par exemple, des touches de fonction avec ce type de séquence d'échappement, en stockant une séquence de commande pour cette clé dans le matériel. Vous aurez toujours besoin d'un appui physique sur la touche pour l'activer.

Mais il y a toujours (comme Hauke ​​l'a si bien marqué "braindead") des personnes désireuses d'ajouter une telle fonctionnalité si elle résout un problème pour elles, ne comprenant pas l'échappatoire qu'elles créent. D'après mon expérience avec les logiciels open source, à cause des nombreux yeux qui regardent le code, cela est moins susceptible de se produire que pour les sources fermées. (Je me souviens que dans le programme de messagerie d'Irix de Silicon Grahpics, vous pouviez inclure des commandes à exécuter sur la machine du récepteur, des chemins réels vers les exécutables, ....)

La plupart des émulateurs de terminaux renvoient une réponse s'ils reçoivent certaines séquences d'échappement (consultez la documentation sur les séquences de contrôle xterm ). Par exemple, vous pouvez envoyer \e[0cà un émulateur de type VT100 et celui-ci renverra les attributs du périphérique, quelque chose comme \e[?1;2c (C’est probablement ce que Keith a observé). Mais ces réponses ne sont pas des chaînes arbitraires. Néanmoins, avoir un exécutable nommé 2cquelque part sur votre système qui fait quelque chose de fatal est une mauvaise idée.

Mise à jour: les risques sont en fait plus importants que je ne le pensais, en raison de la possibilité de définir le titre d'une fenêtre xterm et de le renvoyer à l' aide de séquences d'échappement appropriées ( http://www.securityfocus.com/bid/6940/ ) . Contrairement à l'exemple ci-dessus, le titre peut être une chaîne presque arbitraire.

Cela change le titre du terminal dans GNOME Terminal 3.6.1, à moins qu’il ne soit remplacé par quelque chose comme PS1 :

printf "\033]2;Script Kiddie was here\007"

Ouvrez maintenant une nouvelle fenêtre du terminal GNOME pour tester la catversion:

printf "\033]2;Script Kiddie was here\007" > test.bin
cat test.bin

Oui, cela définit également le titre du terminal.

Il y avait un problème de sécurité avec un code d'échappement qui entraînait l'impression du titre sur la ligne de commande . Vous pouviez ainsi créer un fichier qui, une fois catéd, serait imprimé (je ne suis pas sûr que vous puissiez y insérer une nouvelle ligne). commandes arbitraires. Aie!

Bien que l'utilisation catn'entraîne pas forcément l'exécution de code, les codes d'échappement seront traités de sorte que vous pourriez facilement être induit en erreur en pensant que le script est inoffensif alors qu'il est malveillant.

Voici un exemple de commande que vous pouvez exécuter et qui va créer un script shell "malveillant":

echo -e '#!/bin/sh\necho "...doing something bad here..."\nexit\n\033[A\033[Aecho "Hello dear reader, I am just a harmless script, safe to run me!"' > demo.sh
chmod a+x demo.sh

Lorsque vous inspectez le fichier, cela semble assez inoffensif:

$ cat demo.sh
#!/bin/sh
echo "Hello dear reader, I am just a harmless script, safe to run me!"

Mais devriez-vous réellement l'exécuter ...

$ ./demo.sh 
...doing something bad here...

Le script fonctionne en incluant des codes d'échappement bruts pour déplacer le curseur de quelques lignes vers le haut, de sorte que le reste du script soit écrit au-dessus du code malveillant, en le masquant.

Presque tout autre programme révélera le script correspondant. Seuls les programmes qui ne traitent pas le contenu du fichier (comme cat, moreet less -r) produiront une sortie trompeuse.

Notez cela tailet headproduisez également le même résultat trompeur. Utiliser "less + F" est donc plus sûr que "tail -f".

J'ai certainement expérimenté l' xterminsertion de caractères arbitraires en soi, comme si je les avais dactylographiés. Et à l'occasion, cela a apparemment inclus un caractère de nouvelle ligne, de sorte que j'ai eu ngwerm:0riu: command not foundcomme réponse. Je ne vois aucune raison pour laquelle quelqu'un ne pourrait pas créer un fichier qui enverrait des commandes spécifiques nuisibles. Alors oui, au moins certains terminaux sont susceptibles d'attaques ayant un impact arbitraire.

Un émulateur de terminal affiche simplement les caractères qui lui sont envoyés.

Toute autre chose que simplement imprimer un caractère sur la position actuelle, telle que définir une nouvelle position, changer de couleur, changer de titre, etc., est réalisée à l'aide de séquences d'échappement.

L'ensemble de séquences d'échappement prises en charge est généralement constitué de normes bien définies, telles que ANSI , qui ne définissent pas le moyen de démarrer d'autres processus. Bien qu'il soit possible d'implémenter une telle séquence, je ne suis au courant d'aucun émulateur de terminal permettant intentionnellement de telles choses.

En théorie, un bug tel qu'un débordement de tampon pourrait être utilisé pour déclencher des fonctionnalités arbitraires. Mais cela serait possible dans à peu près n'importe quel autre binaire.

En général, il n’ya généralement aucun risque de gérer un fichier arbitraire. Ma méthode habituelle pour analyser un fichier est la suivante:

$ file <mystery file>
$ strings <mystery file> | less

Ce qui précède me permet de déterminer le type d’un fichier à l’aide de la filecommande, laquelle stringsme permet de vider toutes les chaînes identifiables de fichiers binaires potentiels dont je ne suis pas sûr au sujet de leur lignage.

exemple

$ file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped

$ strings /bin/ls|less
...
across
vertical
single-column
force
never
auto
if-tty
slash
%b %e  %Y
%b %e %H:%M
long-iso
main
posix-
sort_files
?pcdb-lswd
dev_ino_pop
Try `%s --help' for more information.
Usage: %s [OPTION]... [FILE]...
List information about the FILEs (the current directory by default).
Sort entries alphabetically if none of -cftuvSUX nor --sort.
Mandatory arguments to long options are mandatory for short options too.
  -a, --all                  do not ignore entries starting with .
  -A, --almost-all           do not list implied . and ..
...