4 votes

Le fichier batch consomme du cpu et de la RAM en utilisant seulement l'écho ^ ?

tldr : a lancé un fichier batch avec seulement une ligne dedans : echo ^ . Ce fichier consomme 70 à 100% d'un cœur et environ 1k de RAM par seconde... ???

Tout en répondant ce J'ai découvert un comportement étrange dans les fichiers batch de Windows.

Je m'amusais avec les fichiers batch pour montrer au PO que l'on peut avoir une ^ à la fin d'une ligne dans un fichier batch pour la continuation de la ligne, exemple :

fichier test.bat :

echo How are ^
you today ^
my good fellow

La sortie se ferait : How are you today my good fellow

J'étais curieux de savoir si l'invite de commande affichait une More? à partir du fichier de commandes, comme si vous aviez une ligne comme celle-ci dans un fichier de commandes : echo Do you want some ^

Si vous faites ça sur la ligne de commande, cela affichera More? (comme pour plus d'informations) :

C:\>echo Do you want some ^
More?

Cependant, j'ai essayé cette ligne (en ayant UNIQUEMENT cette ligne) dans un fichier batch et un certain comportement inexplicable s'est produit, alors j'ai joué avec le script pour trouver que la seule fois où cela se produit est quand un echo est la dernière ligne et l'instruction ^ est le dernier caractère du fichier batch.

Un dossier rapide à reproduire :

fichier test.bat :

echo ^

L'exécution de ce fichier batch sur ma machine Windows 7 64 bits consommait 70 à 100 % de l'un de mes cœurs et environ 1k de mémoire par seconde !

L'exécution de ce fichier a également ignoré toutes les entrées (à l'exception de CTRL+ pour le terminer), bien qu'après la fin du fichier, l'entrée était toujours envoyée à la console :

C:\>test.bat
(nothing is happening here except CPU/RAM eating)
(I would proceed to type something like "HELLO")
CTRL+C (script ends)
C:\>HELLO
'HELLO' is not recognized an internal .....

Mes recherches (Stack Oveflow, Stack Exchange, MSDN, Google et Bing) n'ont donné aucun résultat susceptible d'expliquer ce comportement étrange dans un fichier de traitement par lots (seulement ce que l'on peut trouver dans le fichier de traitement par lots). ^ sur la ligne de commande et les fichiers de traitement par lots) ; je pense que si la seule ligne d'un fichier de traitement par lots était echo ^ cela terminerait juste le script et ne s'exécuterait pas jusqu'à ce que je CTRL+C en dehors de ça ?

Quelqu'un d'autre a-t-il remarqué ce comportement ou peut-il expliquer ce qui pourrait le provoquer ? De même, cela pourrait-il conduire à des pistes d'attaque possibles sur un système ?

Ce n'est pas un problème majeur (je n'ai pas de fichiers batch qui se terminent en echo ^ ), mais il m'a semblé très étrange qu'une ligne de lot donne lieu à 1k/s ?

(Note complémentaire : je vais essayer cette même situation à travers quelques langages de programmation [.NET, Java et C/C++] et quelques scripts web (JS peut-être ?) pour voir ce qui se passe comme résultat)

4voto

txtechhelp Points 3523

Il s'avère que c'est en fait un bug dans la manière dont la ligne de commande (plus spécifiquement cmd.exe ) analyse les fichiers batch et pourrait conduire à une attaque rapide de type déni de service ; mettre la ligne suivante dans un fichier batch (sans nouvelles lignes) consommera très rapidement des quantités massives de mémoire à cause de ce bogue (à titre d'exemple) :

^ nul<^

Pour faire court, lorsqu'un signe d'insertion se trouve à la fin du fichier, la fin réelle du fichier est "ignorée" et le gestionnaire de fichier est "remis à 0" (essentiellement) afin que le lot soit analysé à nouveau (ad infinitum).

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X