Question:
"Cat-ing" un fichier peut-il être un risque de sécurité potentiel?
Ivan Kovacevic
2014-04-22 07:29:11 UTC
view on stackexchange narkive permalink

J'utilise souvent cat sur la console pour afficher le contenu des fichiers, et de temps en temps, j'attrape accidentellement un fichier binaire qui produit essentiellement du charabia et des bips système. Cependant, aujourd'hui, j'ai rencontré une situation où la sortie de l'utilitaire cat a été redirigée vers l'entrée de la console, donc j'ai des trucs comme ceci:

  -bash: 2c: commande not found-bash: 1 : commande non trouvée-bash: 1: commande non trouvée-bash: 112: commande non trouvée-bash: 112: commande non trouvée-bash: 1: commande non trouvée-bash: 0x1: commande non trouvée-bash: 2c1: commande not found-bash: 2c: commande non trouvée-bash: 1: commande non trouvée-bash: 1: commande non trouvée-bash: 112: commande non trouvée-bash: 112: commande non trouvée-bash: 1: commande non trouvée -bash: 0x1: commande non trouvée-bash: 2c1: commande non trouvée-bash: 2c1: commande non trouvée-bash: 2c1: commande non trouvée-bash: 2c1: commande non trouvée  

...
...

Cela m'a fait penser qu'un fichier binaire spécialement conçu pourrait créer un désordre sur le système?! ... Maintenant, je me rends compte que l'utilisation imprudente de cat est comme ça pas particulièrement intelligent, mais j'aimerais vraiment savoir ce qui se passe ici. Quels caractères produisent l'effet de déverser soudainement le contenu sur l'entrée standard ...

Remarque: j'étais dans le terminal Mac OS X en faisant cela, j'ai en fait appelé diff -a pour comparer deux images de firmware rom et imprimer les différences (je pensais qu'il n'y aurait que quelques octets de différences mais là où presque 8 Mo de différences étaient imprimés à l'écran) Plus tard, j'ai essayé, exprès, de chatter l'un des fichiers et j'ai le même effet que celui que j'ai collé ici.

- UPDATE - - UPDATE - - UPDATE -

J'ai posté ceci ici tard dans la nuit hier et ce matin j'ai essayé de reproduire le comportement et je ne peux pas. Malheureusement, je ne peux pas être sûr si certains caractères d'échappement ont causé l'exécution automatique du charabia du binaire sur la console ou si à la fin du chat il me reste juste un tas de caractères (comme si je les ai collés) sur le ligne de commande et j'ai probablement appuyé accidentellement sur Entrée pour obtenir une ligne claire ...

Quand j'essaye de chatter le fichier en question maintenant, j'obtiens ceci quand il se termine (faites défiler vers la droite pour voir):

  D? k (Fli9p? s? HT? 78 =! g ?? Ès3? &é ?? = ?? 7 ?? K? ̓Kü<ö ???? z (; ????? ?? j ?? > ?? ö? Ivans-MacBook-Pro: FI9826W-2.11.1.5-20140121 NA ivankovacevic $ 1; 2c1; 2c1; 2; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c; 1; 1; 112; 112; 1; 0x1; 2c1; 2c; 1; 1; 112; 112; 1; 0x1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1 / code> 

Mon invite actuelle est:

  Ivans-MacBook-Pro: FI9826W-2.11.1.5-20140121 NA ivankovacevic $  

Où:

  FI9826W-2.11.1.5-20140121 N Un  

est le répertoire de travail actuel. Comme vous le voyez, il a été camouflé dans le charabia binaire et j'ai peut-être appuyé sur Entrée par réflexe ou quelque chose comme ça. Cela en soi est un peu faux de la part de chat car évidemment mon message aurait pu être encore mieux «camouflé». Mais c'est moins grave que je ne le pensais au départ. Bien que je ne sois toujours pas sûr à 100% qu'il ne s'est pas exécuté automatiquement la nuit dernière lorsque j'ai essayé, car il y avait aussi une autre chose particulière qui s'est produite hier soir, avant cela. J'ai appelé cat sur un autre fichier très similaire qui a provoqué la fermeture de l'application Terminal avec:

  Type d'exception: EXC_BAD_ACCESS (SIGSEGV) Codes d'exception: KERN_INVALID_ADDRESS à 0x00007fcb9a3ffffa  

Maintenant je pense que peut-être une combinaison de ces deux événements a provoqué l'exécution automatique de charabia sur la console. Mais je ne peux pas reproduire ce comportement à nouveau.

Les fichiers en question sont des firmwares pour une caméra IP Foscam, voici les liens:

Site international: http://foscam.com/Private/ProductFiles/FI9826W-2.11.1.5 -20140120.zip
Et puis le fichier à l'intérieur: FI9826W_app_ver1.11.0.40_OneToAll.bin final

appeler cat sur celui-là entraînera la fermeture de Terminal.

Site américain: http://foscam.us/downloads/FI9826W-2.11.1.5-20140121%20NA.zip
puis le fichier: FI9826W_app_ver1. 11.0.40_OneToAll_A.bin

cat-ing que l'on va provoquer cette pâte de 1; 2c1; 2c1; 2; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c. ... caractères sur la ligne de commande

Ah, ces souvenirs réconfortants d'une époque où les bombes ANSI étaient présentes et largement connues ...
Sept réponses:
#1
+60
mr.spuratic
2014-04-23 02:38:43 UTC
view on stackexchange narkive permalink

Oui , c'est un risque potentiel, voir CVE-2003-0063, ou CVE-2008-2383 ou CVE- 2010-2713, ou CVE-2012-3515 ou OSVDB 3881, ou CVE-2003-0020 ou tout autre similaire ceux listés ici... Quelques autres dans les commentaires ci-dessous également.

Mettre à jour ce n'est pas seulement un risque potentiel , c'est un risque réel . rxvt-unicode (versions 2.7—9.19, corrigé dans 9.20) autorise l'accès en lecture / écriture aux propriétés de la fenêtre X, cela peut permettre l'exécution assistée par l'utilisateur de commandes arbitraires, ce problème a été attribué CVE -2014-3121, plus de détails ici https://bugzilla.redhat.com/show_bug.cgi?id=1093287.

Plus récemment (octobre 2019) Les versions iTerm2 jusqu'à la v3.3.5 se sont avérées avoir la même classe de problème: l'affichage de contenu malveillant peut activer la commande intégrée tmux et permit exécution, voir CVE-2019-9535.

Ce sujet a également une bonne couverture ici: https://unix.stackexchange.com/questions/73713/how- safe-is-it-to-cat-an-arbitrary-file et une analyse approfondie du problème sous-jacent de Gilles ici: https://unix.stackexchange.com / questions / 15101 / comment-éviter-les-attaques-de-séquence-d'échappement-dans-les-terminaux.


Explication

Ce que vous observez est un côté -effet du comportement de certaines séquences d'échappement: certaines ils remplissent des caractères (contenant généralement également des séquences d'échappement) directement dans le tampon d'entrée du terminal . Tout cela au nom de la rétrocompatibilité, bien sûr. Les échappements xterm standard qui sont décrits en utilisant le terme "Report <something>" le font. Ce comportement permet aux programmes d'interroger / définir les propriétés du terminal (ou d'autres) " dans la bande" plutôt que via ioctls ou une autre API.

Comme si cela ne suffisait pas, certaines de ces séquences peuvent contenir une nouvelle ligne , ce qui signifie que tout ce qui lit depuis le terminal (votre shell) verra ce qui semble être une commande utilisateur complète .

Voici une manière intéressante d'utiliser ceci, avec read de bash pour imprimer un échappement (comme une invite) puis immédiatement lire et diviser la réponse en variables:

  IFS = ';' read -sdt -p $ '\ e [18t' csi8 rows colsecho rows = $ rows cols = $ cols  

Ces séquences peuvent varier selon le terminal, mais pour rxvt et dérivé, l'échappement requête graphique inclut une nouvelle ligne (exemple utilisant les chaînes bash et $ '' , voir doc / rxvtRef. txt dans la source) `:

  $ echo $ '\ eGQ' $ 0bash: 0: commande introuvable  

Cet échappement envoie \ 033G0 \ n dans le tampon d'entrée du terminal (ou chiffre 1 au lieu de 0 si vous avez un rxvt ).

Alors, combinez cet échappement avec d'autres séquences qui se comportent de la même manière:

  echo $ '\ x05' $ '\ e [>c' $ '\ e [6n '$' \ e [x '$' \ eGQ ' 

pour moi cela provoque 11 tentatives d'exécuter diverses commandes: 1 , 2c82 , 20710 (ma chaîne de version rxvt ), 0c5 , 3R (5 et 3 étaient les curseurs coords), 112 et 0x0 .

Exploitable?

Avec rxvt et les émulateurs de terminaux les plus récents, vous ne devriez "que" pouvoir créer un ensemble limité de séquences principalement numériques. Dans les anciens émulateurs de terminal, il était possible (certains CVE répertoriés ci-dessus) d'accéder au presse-papiers, à l'icône de la fenêtre et au texte de la barre de titre pour créer plus de chaînes malveillantes pour l'invocation (une légère exception actuelle est si vous définissez la answerbackString X chaîne de ressource, mais qui ne peut pas être définie directement à l'aide de cette méthode). La faille permet alors un accès arbitraire en lecture et en écriture à quelque chose qui passe pour l'état ou le stockage dans des séquences d'échappement qui remplissent les données dans le tampon d'entrée.

rxvt nécessite des modifications au moment de la compilation pour être activé, mais urxvt a utilement une option de ligne de commande -insecure qui active certaines des fonctionnalités les plus intéressantes:

  $ echo $ '\ e] 2 ;; uptime; \ x07' $ '\ e [21 ;; t' $ '\ eGQ' bash: l: commande non trouvée 17: 59: 41 jusqu'à 1448 jours, 4:13, 16 utilisateurs, moyenne de charge: 0.49, 0.52, 0.48bash: 0: commande introuvable  

Les trois séquences sont:

  1. \ e] 2; ... \ x07 définir le titre de la fenêtre;
  2. \ e [21 ;; t titre de la fenêtre de requête, place dans le tampon d'entrée;
  3. \ eGQ capacité graphique de requête, qui ajoute \ n au tampon d'entrée.

Encore une fois, selon terminal, d'autres fonctionnalités telles que la taille de la police, les couleurs, la taille du terminal, le jeu de caractères, d'autres tampons d'écran et plus peuvent être accessibles via des échappements. La modification involontaire de ceux-ci est au moins un inconvénient, sinon un problème de sécurité pur et simple. Les versions actuelles de xterm limitent les fonctionnalités potentiellement problématiques via les ressources "Autoriser *".

CVE-2014-3121

Avant la v9.20, urxvt ne protégeait pas également l'accès en lecture et en écriture aux propriétés X ( principalement utilisées par les gestionnaires de fenêtres). L'accès en lecture Write (ou plus précisément, l'accès à des séquences qui font écho à des chaînes potentiellement arbitraires) nécessite désormais l'option -insecure .

  $ echo $ '\ e] 3; xyzzy = disponibilité; date +% s; \ x07' $ xprop -id $ WINDOWID xyzzyxyzzy (UTF8_STRING) = 0x75, 0x70, 0x74, 0x69, 0x6d, 0x65, 0x3b, 0x64, 0x61, 0x74, \ 0x65, 0x20, 0x2b, 0x25, 0x73, 0x3b  

Ceci peut être utilisé de manière triviale pour remplir des chaînes arbitraires dans le tampon d'entrée du terminal. Lorsque la séquence d'échappement pour interroger une propriété est invoquée (avec \ eGQ utile qui ajoute une nouvelle ligne):

  $ echo $ '\ e] 3;? Xyzzy \ x07 '$' \ eGQ '$ 3; disponibilité; date +% s; 0 bash: 3: commande non trouvée 17:23:56 jusqu'à 1474 jours, 6:47, 14 utilisateurs, charge moyenne: 1,02, 1,20, 1,17 1400603036 bash: 0: commande introuvable  

Commandes multiples, préservant les espaces blancs et les métacaractères du shell. Ceci peut être exploité de différentes manières, en commençant par la recherche d'un binaire non fiable bien sûr, idées en HD Article court de Moore (2003).


Suivi

Pour la séquence d'échappement, vous demandez: 1; 112; 112; 1; 0x1; 2 Il s'agit de: Demander les paramètres du terminal (DECREQTPARM) et Envoyer les attributs de périphérique :

  $ echo $ '\ e [ x '$' \ e [0c '; 1; 1; 112; 112; 1; 0x1; 2c  

Le second ( \ e [0c ) est identique à ^ E (en utilisant rxvt ). Il y a aussi des séquences d'échappement. la séquence complète écrite pour chacun est, respectivement:

  \ e [1; 1; 1; 112; 112; 1; 0x \ e [? 1; 2c  
Bons liens! Voici quelques exemples spécifiques d'Apple http://www.cvedetails.com/cve/CVE-2005-1341/ ou http://www.cvedetails.com/cve/CVE-2009-1717/ et il y en a probablement d'autres. .
Cool mise à jour! Vous avez dit "La version actuelle d'un émulateur de terminal populaire a ce problème", pouvez-vous partager avec nous quel émulateur de terminal c'est? Et qui a découvert la vulnérabilité? Tu? L'ami d'un ami?
J'ai trouvé le problème aujourd'hui (en recherchant des chaînes de format intéressantes), pas de noms ni de détails jusqu'à ce qu'il soit coordonné avec les auteurs.
Je respecte totalement ça! J'espère cependant que vous mettrez à jour les informations lorsque les auteurs auront fourni le correctif. Et btw. votre dernière mise à jour à la fin, qui explique les caractères que j'ai obtenus, est superbe. Merci! Votre réponse est ma réponse préférée pour le moment ...
Ça ira. Ma réponse spéculative (pas de machine OS X à portée de main) sur le segfault est refusée pour la même raison.
Merde, je meurs de curiosité maintenant pour les deux choses. Un http://i.imgur.com/eNoBclw.jpg ferait-il l'affaire? :)
Je suis en contact avec les auteurs, je mettrai bientôt à jour la réponse avec les détails promis.
#2
+47
F. Hauri
2014-04-22 10:40:37 UTC
view on stackexchange narkive permalink

Oui.

Nouvel ajout 25/01/2020:

Depuis que je suis passé de LATIN-1 encodage en UTF-8 comme encodage par défaut dans la plupart de mes systèmes, j'ai trouvé des fonctionnalités intéressantes autour de ça ( il y a maintenant deux longueurs pour une chaîne) ...

Pour un exemple, comme j'aime jouer avec , j'ai demandé pourquoi la localisation bash ne fonctionnera pas avec les chaînes multilignes. Cette fonctionnalité bash présente un bogue, où la solution de contournement consiste à utiliser eval . S'il ne s'agit pas d'une faille de sécurité , cela pourrait en devenir ou en produire une ...

Dans toutes les évolutions de presque tout (langages, bibliothèques, outils, protocoles, applications, matériel, installateurs , consoles, etc ...) comme de nouvelles fonctionnalités, avec potentiellement de nouveaux bugs ...

Heureusement, elles sont aussi rares qu'elles sont rapidement corrigées (près de un jour de révèlent), mais ils le sont!

Alors définitivement oui, restez prudent!

Utilisation correcte de la commande cat .

Comme vous semblent utiliser un émulateur de terminal moderne, certaines séquences d'échappement pourraient être utilisées pour modifier le Tampon du clavier .

Il pourrait y avoir des commandes shell appropriées injectées.

Vous pouvez utiliser l'argument -e de cat pour opération sûre, voir man cat .

  -e équivalent à -vE -E, --show-ends affiche $ à la fin de chaque ligne -v , --show-nonprinting utilise les notations ^ et M-, sauf pour LFD et TAB  
block quote>

Puis

  cat -e fichier suspect.rawcat -e fichier suspect.raw | less  

ou sous :

  less < < (cat -e suspectfile.raw)  

ou même

  qui less cat / usr / bin / less / bin / catrawless () {/ usr / bin / less < < (/ bin / cat -e "$ @ ");}  

Addendum

En fait, c'était possible , dans le passé ... Comme cela est devenu un problème, ce type de fonctionnalités a été rapidement supprimé , mais ...

Lorsque vous lisez commande introuvable , cela implique que quelque chose a été effectivement injecté.

L ' injection principale la fonctionnalité qui n'a pas été supprimée est la séquence identifiez-vous , utilisée dans de nombreuses encapsulations VT-100.

Cette séquence est Escape Z qui injectera la chaîne 1; 2c dans la mémoire tampon de votre clavier, ce qui signifie VT-100 (selon la convention AVO).

En parlant de cat , vous pouvez essayer:

  cat <<< $ '\ 033Z'  

et ensuite ligne demandée, vous verrez 1; 2c (ou peut-être avec un autre numéro, selon le terminal utilisé) comme si vous les avez touchés.

.. . et

  cat -e <<< $ '\ 033Z' ^ [Z $  

-e = > -vE , -v transforme \033 en ^ [ et -E mettre un signe $ en fin de ligne (et rien ne sera mis sur la ligne suivante, vous le tampon du clavier n'est pas affecté).

Vous pouvez trouver beaucoup de choses amusantes au Guide de l'utilisateur du VT100 (comme: cat <<< $ '\ 033 # 8 ';)

(C'était un terminal moderne ! Dans le passé ...)

Essayer d'utiliser

Il y a une petite commande bash pour vider la mémoire tampon du clavier et obtenir son contenu:

  chat <<< $ '\ 033Z'; buf = ''; while read -t .1 -n 1 chr; do buf + = "$ chr"; done; printf "\ n> |% q | < \ n "$ buf ^ [[? 1; 2c> | $ '\ E [? 1; 2c' | <  

Et une petite fonction pour tester n'importe quelle chaîne:

  trySeq () {printf -v out "$ 1" echo -n "$ out" buf = "" while read -t.1 -n1 char do buf + = "$ char" done
["$ buf"] && printf "\ r |% q | -> |% q | < \ e [K \ n" "$ out" "$ buf"}  

Donc Je pourrais essayer:

  pour seq dans $ '\ e [' {c, {1..26} {n, t, x}}; do trySeq "$ seq"; done | $ '\ E [c' | -> | $ '\ E [? 65; 1; 9c' | < | $ '\ E [1x' | -> | $ '\ E [3; 1; 1; 120; 120; 1; 0x '| < | $' \ E [5n '| -> | $' \ E [0n '| < ...  

(peut-être avec un effet sur votre console)

Exemple pour le plaisir

Imaginez, certains pourraient mettre quelque chose comme ça dans votre environnement:

  $ source < (printf '% dc ( ) {printf "Vous \\ 047avez été frappé \\ 041 \\ n";}; \ n '{0..100})  

De là, si vous

  $ cat <<< $ '\ e [c' $ 65; 1; 9c_  

Le curseur restera à la fin de la ligne d'invite de commande. À partir de là, si vous appuyez machinalement sur Retour au lieu de Ctrl c , vous lirez quelque chose comme:

  $ 65; 1; 9cbash: 65: commande non trouvéebash: 1: commande introuvableVous avez été touché! $ _  

Et maintenant?

À partir de là, malheureusement, il n'y a pas de standard.

Tous les l'implémentation du terminal virtuel pourrait prendre en charge la norme ANSI complète et / ou la norme DEC complète ...

Mais comme il y a des problèmes de sécurité, beaucoup ne le font pas ...

Vous pourriez observer un comportement en utilisant un terminal que vous n'observeriez pas en utilisant un autre ...

xterm, console linux, gnome-terminal, konsole, fbterm, Terminal (Mac OS) ... la liste des émulateurs de terminaux n'est pas si courte!

Et chacun d'eux a ses propres bogues et limitations par rapport aux normes DEC et ANSI.

Dans pactice, vous pouvez trouver une console virtuelle qui pourrait être plus en vedette que d’autre et où l ’ injection de clavier pourrait briser votre sécurité.

C’est une des raisons parce que je préfère utiliser toujours le même (ancien) xterm plutôt que d'autres outils plus fonctionnels.

Oh? Vous souhaitez partager des détails? Dans la mesure où c'est vrai, il s'agit d'une vulnérabilité de sécurité critique dans l'émulateur de terminal.
C'est pourquoi certaines des séquences d'échappement ANSI sont généralement désactivées dans les terminaux / émulateurs modernes.
chat -e, bon conseil! Je suis toujours intéressé si vous pouviez peut-être élargir votre réponse avec un exemple de ces séquences d'échappement pour modifier le tampon du clavier qui pourrait éventuellement expliquer cela.
Quand je tape `man cat` tout ce que je vois, c'est que` -e` est "équivalent à -vE", mais aucune information n'est donnée sur -vE ...
La convention est que les indicateurs à un seul caractère peuvent être regroupés, donc «-vE» est identique à «-v -E». c'est-à-dire que la page de manuel vous demande de consulter la documentation pour les indicateurs `-v` et` -E` qui signifient "afficher les caractères non imprimables en utilisant les notations" ^ "et" M-"et" Afficher les fins de ligne comme un caractère «$», respectivement.
@F. Hauri: Merci pour l'addendum. Cependant, comme je l'ai déjà mentionné dans le commentaire à la réponse du dr jimbob, la séquence Terminal ESC-Z de Mac OS X ne produit rien d'autre qu'une nouvelle ligne. CSI-ESC-Z obtient ce "1; 2c". CSI est un introducteur de séquence de contrôle: ASCII octal 33 (ESC) + crochet gauche. La séquence d'échappement complète qui fonctionne pour moi est donc: echo $ '\ 033 [\ 033Z'. J'ai découvert cela uniquement en regardant le fichier du firmware, je ne l'ai trouvé documenté nulle part ...
@IvanKovacevic - `echo -e '\ x1BZ'` fonctionne sous Mac OS X 10.9 (ainsi que Linux), Terminal 2.4, avec mes paramètres de terminal par défaut (déclarés comme xterm-256color, ne permettent pas l'application VT100).
@dr jimbob: Vous avez raison! Mais il se passe quelque chose d'étrange sur Mac (OS X 10.9.2, xterm-256color) et c'est pourquoi je l'ai vécu comme si cela ne fonctionnait pas. Quand je tape echo -e '\ x1BZ' pour la première fois ... ça marche. Si j'appuie ensuite sur la touche haut pour obtenir la dernière commande utilisée et que je la relance, cela ne fonctionne plus (seule une nouvelle ligne est imprimée). Puis seulement après un certain temps, après avoir tapé plusieurs autres commandes régulières, il recommence à fonctionner! Vraiment étrange ... Je l'ai aussi essayé maintenant sous Linux, et ça marche à chaque fois!
Pour référence, PuTTY par défaut répondra à un Control-E avec la chaîne "PuTTY" (mais vous pouvez lui faire dire autre chose si vous le souhaitez). Ce qui n'est pas vraiment un problème de sécurité à moins que quelqu'un n'écoute votre connexion ou n'injecte des trucs ... auquel cas, si c'est votre machine, vous avez déjà des problèmes beaucoup plus graves que quelqu'un sachant que vous utilisez PuTTY.
Merci F. Hauri pour votre réponse! Vous y avez fait un gros effort! Mais au final, j'ai dû choisir et M. Spuratic a également fourni une superbe réponse. Dans l'ensemble, je crois que vous serez satisfait de tous les votes positifs récompensés!
Hmmm je suis d'accord, la réponse d'@mr.spuratic est riche. Mais j'apporte des outils utilisables pour faciliter les tests, (j'espère que vous l'avez essayé) ... Quoi qu'il en soit j'ai eu ma 1ère médaille d'or \ @SO avec cette réponse! Alors c'est bon! ;-). (P.S: En cas de problème avec la fonction, peut-être que jouer avec le paramètre timeout (`-t .01`) pourrait aider)
wow, un badge en or! Je viens de le remarquer. Toutes nos félicitations! :) Vous le méritez. Comme je l'ai déjà dit, j'ai vu l'effort (en plusieurs itérations) que vous avez mis dans cette réponse. Votre code de test est vraiment intelligent! J'ai eu du mal à décider des réponses, et je voulais récompenser à la fois les vôtres et celles de M. Spuratic. Puisque vous avez déjà eu tellement de votes positifs (le mien inclus bien sûr). Récompenser la réponse de M. Spuratic avec la prime et le drapeau accepté semblait être la meilleure chose pour rétablir l'équilibre dans l'Univers! ;-)
Existe-t-il un moyen de désactiver un tel comportement afin que je ne change pas accidentellement ma coquille lors de la mise en cage?
Pas vraiment, mais vous pouvez utiliser de nombreuses implémentations de terminaux différentes. XTerm peut être basculé entre les modes * vt100 * et * tektronix *, qui ont des séquences de contrôle de manipulation de fenêtre totalement différentes.
Ironiquement, xterm est probablement le moins sécurisé des systèmes traditionnels, et il a _far_ plus de "fonctionnalités" que la plupart (des fonctionnalités héritées dont vous n'aurez jamais besoin mais qui sont toujours présentes, comme le support de certains matériels old-school).Sans oublier que de nombreux émulateurs de terminaux (comme rxvt et urxvt) ne sont que des fourches de xterm.
#3
+7
JasperWallace
2014-04-22 13:30:57 UTC
view on stackexchange narkive permalink

Les terminaux en verre "réels" avaient une séquence d'échappement pour imprimer l'écran sur une imprimante. Ils l'ont fait en exécutant une commande et en acheminant le contenu de l'écran actuel vers le stdin de la commande d'impression.

La commande pouvait être configurée par une autre séquence d'échappement.

La manière classique d'exploiter c'était pour créer des fichiers avec des noms qui incorporaient la séquence d'échappement pour définir la commande d'imprimante et le changer en un script de votre choix, puis avoir un deuxième fichier avec la séquence d'échappement d'impression.

Quand quelqu'un alors a exécuté ls dans ce répertoire, ils finiraient par exécuter votre code. Ce qui était bien s'ils étaient l'utilisateur root !

En théorie, les émulateurs de terminaux modernes ne devraient plus faire ce genre de chose.

Terminal.app semble être basé sur le NextStep nsterm, il peut donc contenir toutes sortes de bizarreries.

Essayez peut-être de préciser quels octets exacts produisent les messages command not found ?

On dirait qu'il existe des séquences d'échappement pour monter et descendre le terminal:

http://the.taoofmac.com/space/apps/Terminal

quelques informations supplémentaires ici:

http://invisible-island.net/ncurses/terminfo.src.html#toc-_Apple__Terminal_app

Si vous voulez envoyer du contenu vers le stdin d'un programme,

  programme -para mètres < / chemin / fichier.ext  
`" contenu de l'écran actuel à son stdin "` - le contenu de l'écran n'est pas stdin.
@Ruslan: Il signifie le stdin de la commande vers laquelle le contenu de l'écran est redirigé.
Ensuite, ça devrait être "c'est" pas "c'est"
@JasperWallace: Cool info! Exemples: Pour minimiser Terminal.app: echo -e '\ x1B [2t' Pour minimiser-maximiser echo -e '\ x1B [2t \ x1B [5t' :)
#4
+6
tylerl
2014-04-22 08:38:13 UTC
view on stackexchange narkive permalink

En général, il n'y a pas de vulnérabilité, mais évidemment si vous l'utilisez mal, vous pouvez en créer une.

L'impression du contenu d'un fichier binaire produit des bips car le caractère 7 est l'ancienne commande de terminal pour que la machine émette un bip, et certains programmes de terminal respectent toujours cette commande. Mais de par sa conception, il n'y a rien qui puisse vous blesser. Dans le pire des cas, ouvrez simplement une nouvelle fenêtre de terminal pour annuler tout désordre qui aurait pu être créé.

Maintenant, si vous avez redirigé le contenu d'un fichier vers un shell de commande, c'est une autre affaire. Vous pouvez le faire en acheminant la sortie de quelque chose vers / bin / bash (généralement mal vu du point de vue de la sécurité) ou vous pourriez peut-être l'avoir copié et collé par inadvertance dans votre terminal. Généralement mal avisé.

Mais tant que vous n’exécutez pas la chose, tout va bien.

Dans ce cas, je viens de taper: cat . Je n'ai donc pas collé une fausse commande dans la console, mais vérifiez ma mise à jour de la question que je viens d'écrire.
#5
+4
dr jimbob
2014-04-23 02:40:12 UTC
view on stackexchange narkive permalink

Ce que vous voyez, ce sont des séquences de contrôle xterm.

Les séquences de contrôle sont activées lorsqu'elles sont vues en sortie dans le terminal; Par exemple, lorsque vous créez un fichier contenant des octets ASCII non imprimables.

Dans votre exemple, la séquence de contrôle est ESC Z (octets 1B 5A ) qui renvoie l'ID du terminal - sous forme de commande dans le terminal.

Vous pouvez l'essayer vous-même:

  echo -e '\ x1BZ'  

(Vous pouvez également écrire ESC comme \ e ou Z comme \x5A).

Il y en a d'autres amusants aussi:

  echo -e ' \ eF '# déplacer l'invite vers le bas du terminal.echo -e' \ ec '# Réinitialiser le terminal  
En fait, echo -e '\ x1BZ' dans mon cas affiche juste une ligne vide. Cependant echo -e '\ x1B [\ x1BZ' imprime que "1; 2c" sur la ligne de commande que je recevais à plusieurs reprises après avoir trouvé ce fichier binaire du firmware. C'est et [qui est connue sous le nom de séquence d'échappement , suivie de Z. Cependant, je n'ai aucune idée de ce que cela signifie 1; 2c. Est-ce l'ID du terminal?!
@IvanKovacevic Oui, voir mon * addendum *. (Ma première réponse a été trop rapide. Désolé;)
@dr jimbob: Je n'avais pas raison, echo -e '\ x1BZ' fonctionne, mais il a un comportement étrange sur Mac OS X. Si je le lance pour la première fois et que je supprime les caractères affichés, appuyez sur Entrée pour obtenir une nouvelle invite claire (Parce que l'écho qui laisse du charabia devant la ligne d'invite également, ou à l'arrière, dépend de la façon dont vous le regardez). Ensuite, si j'essaie de rappeler la dernière commande avec la touche haut et de la rappeler, cela ne fonctionne plus ... Juste une nouvelle ligne est imprimée. C'est pourquoi j'ai d'abord pensé que cela ne fonctionnait pas, parce que je l'ai déjà appelé ... Sous Linux, cela fonctionne indépendamment à chaque fois.
Et echo -e '\ x1B [\ x1BZ' fonctionne également à chaque fois. Je suppose que la séquence CSI le réinitialise.
`alias clear =" echo -e '\ ec' "` Enfin, un * clear * dans cygwin <3
#6
+4
Ivan Kovacevic
2014-04-23 09:20:20 UTC
view on stackexchange narkive permalink

Je vais ajouter cette information ici sans réelle intention de répondre à ma propre question.Les caractères qui peuvent être injectés sur la ligne de commande tout en imprimant d'autres caractères, mieux connus sous le nom de séquences d'échappement, sont définis vraiment bien sur ce site ( Merci F. Hauri , de l'avoir mentionné):
http://vt100.net/docs/vt100-ug/chapter3.html

Sous le chapitre: Rapports convenient


Rapport de position du curseur

Invoqué par ESC [ 6 n
La réponse est ESC [Pl; Pc R
Pl = numéro de ligne; Pc = numéro de colonne

Rapport d'état

Appelé par ESC [5 n
La réponse est ESC [0 n (terminal ok)
ESC [3 n (terminal pas ok)

Que faites-vous

Appelé par ESC [c ou ESC [0 c
La réponse est ESC [? 1 ; Ps c

Ps est le paramètre "option present" avec la signification suivante:

Ps Signification
0 Base VT100, pas d'options
1 Options de processeur (STP)
2 Option vidéo avancée (AVO)
3 AVO et STP
4 Option de processeur graphique (GPO)
5 GPO et STP
6 GPO et AVO
7 GPO, STP et AVO

Alternativement invoqué par ESC Z (non recommandé). La réponse est la même.


ESC est ASCII décimal 27 ou octal 33 ou hexadécimal 1B.

Donc, pour obtenir par exemple la position actuelle du curseur imprimée out, ou mieux dit injecté dans votre ligne de commande existante, vous appelleriez:

  echo -e '\ 033 [6n'  

et la sortie serait être quelque chose comme ceci:

  7; 1R  

Vous pouvez déplacer la position du curseur avec la séquence d'échappement suivante

  echo -e '\ 033 [10; 20H'  

10 - ligne 10
20 - colonne 20

Cependant, il ne déplace pas la position de la colonne (il se déplacer dans les lignes) car le terminal le réinitialise probablement au début de la ligne. Quoi qu'il en soit, si vous interrogez la position du curseur juste après cela, il va "coller" sur la console la position de colonne définie:

  echo -e '\ 033 [10; 20H \ 033 [6n'  

sortie:

  0; 20R  

C'est ainsi que vous pouvez obtenir différentes sorties injectées ('collées') sur la console, c'est loin d'être un véritable exploit car cela ne donnera que différentes combinaisons de nombres qui peuvent être sorties, mais là encore peut-être combinées avec autre chose. Qui sait.

Dans mon cas où j'ai cat-ed l'image du firmware, j'ai beaucoup de: 1; 2c Maintenant je sais que c'est le "What Are You" rapport, de ce qu'est mon terminal, où 2 signifie: option vidéo avancée (AVO).

Dans l'ensemble, il est certainement préférable d'éviter de télécharger sans réfléchir un fichier ...
Comme déjà suggéré ( également par F. Hauri ), utilisez au moins cat -e

#7
-1
paul
2014-04-23 15:42:41 UTC
view on stackexchange narkive permalink

Il y a des risques évidents à envoyer un fichier aléatoire à un interpréteur de quelque sorte que ce soit, mais unix n'est pas configuré pour protéger les utilisateurs de leur propre stupidité. Le simple fait d'utiliser cat filename peut gâcher votre affichage, mais cela ne devrait rien endommager.

Si vous utilisez cat pour afficher les fichiers et identifier leur type Je suggère que vous vous renseigniez sur le fichier (vous indique quel est le fichier) et less qui vous avertiront si vous regardez des données binaires, et ne videra pas un Archive du programme d'installation de 100 Mo sur votre console. zless ouvrira les fichiers gzip de manière transparente.

Transférer un fichier aléatoire à un interpréteur (c'est-à-dire bash) est, bien sûr, extrêmement dangereux. Mais ce n'est pas ce dont nous discutons ici. Afficher uniquement du contenu, avec chat, qui, comme l'histoire l'a montré, PEUT produire des dommages. Vérifiez la réponse de M. Spuratic.
Pour ajouter à la réponse de Paul, il a été dit maintes fois, mais les vieilles habitudes sont mortes: n'utilisez pas le chat pour cela, utilisez moins ou un éditeur de texte.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...