57

This simple batch file in relatively short order consumes all available memory on Windows 7 (x64). What's going on? and what precautions can be taken to ward against it?

any-invalid-command-you-like-here ^

Apparently necessary preconditions to exhibit the effect:

  • the caret ^ is the very last thing in the file, and the script is not terminated with a newline
  • the caret is preceded by at least 2 spaces or characters, e.g. if the dots in the following represent spaces the memory leak will not be triggered .^, while this one will ..^ (just slowly)

In this Process Explorer screen shot, the script had been running about 30 seconds, consumed 2.9GB, and was still climbing at a steady rate:

2.9GB memory consumed and still climbing

If you're going to experiment with this, make sure you can get at the Close Window [X] control or have a Task Manager or Process Explorer fired up and ready as Ctrl-C, Ctrl-Break, Alt-F4 have no effect.

It appears multiple carets will cause the memory usage to ramp up much more quickly. The first time I encountered this there wasn't enough memory available in 1 or 2 minutes to do simple things like Alt-Tab and even the 3 finger salute Ctrl-Alt-Del was ineffective. I had to hard power off the machine.

smci
  • 32,567
  • 20
  • 113
  • 146
matt wilkie
  • 17,268
  • 24
  • 80
  • 115
  • No, i got two error messages (XP): `the following string is too long` & `syntax error` (translated). After that the script terminated. – Endoro Mar 17 '13 at 22:55
  • 1
    I added tag:[tag:security] because this could be used maliciously without much fuss to bring a machine to it's knees. Not sure if that is inappropriate use of that tag; remove if so. – matt wilkie Mar 18 '13 at 21:29
  • 5
    I can envision thousands of people on the planet running this on a coworkers machine when they left it unlocked... just open a cmd window, execute, minimize the window and walk away.. – NotMe Mar 18 '13 at 21:45
  • 3
    Fixed in Windows 10. – user202729 Sep 19 '18 at 08:17

1 Answers1

46

Thoughts

The cause of this (from my understanding) is due to the cmd interpreter looking for a character to escape since the ^ is the batch escape character. Instead of properly identifying the end of file eof in this scenario, cmd just keeps looping and initializing something while looking for the character to escape.

Reproduced on Windows 8 Pro (64) with cc^^^ (Multiple carets used to speed up the leak).

Trials

cc^ infinite loop and leaks very slowly.

cc^^ crashes with normal invalid command error.

cc^^^ infinite loop and leaks faster.

cc ^ infinite loop and leaks very slowly.

cc ^^ crashes with normal invalid command error.

cc ^^^ infinite loop and leaks faster.

cc"^ crashes with normal invalid command error.

cc"^^ crashes with normal invalid command error.

cc"^^^ crashes with normal invalid command error.

Notes

  • Only infinite loop and leaks when carets ^ are used literally (outside of quotations). When quotation added the script crashes with standard invalid command error.
  • Only infinite loop and leaks when batch file is encoded as UTF-8 or ASCII. When UTF-16, the script crashes with standard invalid command error.
  • Must be an odd number of carets as to not escape the last caret.

Precautions

  • Make sure no batch scripts end with a caret ^ (0x5E) or at least an odd number of carets.
  • Or encode them in UTF-16.
Community
  • 1
  • 1
David Ruhmann
  • 11,064
  • 4
  • 37
  • 47
  • 6
    Thanks for the extended trial info and likely explanation. I didn't think of testing encoding. Another way of phrasing the first precaution might be "always end with a blank line", something stock notepad.exe has done for as long as I can remember. Maybe this is one reason why ;-) – matt wilkie Mar 18 '13 at 04:54
  • 1
    @mattwilkie Thanks, and I like your precaution wording the best. **"always end with a blank line"** **`:)`** – David Ruhmann Mar 18 '13 at 12:39
  • 14
    As it turns out, this is actually a bug in the command line parser and how it parses batch files. More specifically, a logic error; if a caret is at the EOF, then the real EOF is 'ignored' and 'stepped over', reseting the file handle to 0, thus reparsing the script. See my detailed question here for more info regarding it all: http://stackoverflow.com/questions/23284131/could-this-cmd-exe-batch-file-parsing-bug-lead-to-other-exploits-nul-in – txtechhelp Apr 25 '14 at 04:33
  • 5
    @txtechhelp Here's an [archived version](https://web.archive.org/web/20170814061717/https://stackoverflow.com/questions/23284131/cmd-exe-parsing-bug-leads-to-other-exploits) of your question since the original was removed. – Engineer Toast Aug 03 '18 at 12:29