Windows batch processing Parsing Vulnerability

Windows batch processing Parsing Vulnerability

Before starting this article, please note that this is a very redundant information security notice. For Windows Control Command operators, I may find a BUG that can be attacked by simple batch processing files. This BUG exists on 64-bit and 32-bit machines later than Windows 2000. It is a batch parsing error. If no quota is set, the software ().exe) is installed in windows. Users with any permission can start to parse the batch file by setting the cmd.exe command. The location of the parsing error (the failure code can explain the cause) is included ). This is not a remote control layer BUG. It is only a DoS type that requires user requests to run (or use it as a startup item ). But because of its simplicity and the popularity of Windows systems, I personally think it is worth your eye.

Please note that I am not responsible for the system crash if you enable these batch files! The task manager ends the PID of the runaway script to prevent you from running it.

Tldr: a batch processing file containing only ^ nul <^ may cause a huge memory leakage. A batch processing file containing only ^ | ^ may cause the command line infinite recursion and crash. This behavior can lead to some interesting batch processing programming. Of course, I'm referring to the logic error that occurs when cmd.exe processes batch files in the operating system of windows2k6.

0x01

When I reply to another question raised by a user, I encounter a very interesting Batch File Parsing exception. If ^ is the last character of the file, memory leakage may occur. The last character of the inserted file cannot be \ n (linefeed), because \ r (carriage return) has been executed before the delimiters, so this does not happen, and the parser works normally and nothing can be tracked (when ^ \ r \ t is inserted, the parsing becomes ^ \ r "\ t" and is ignored ). Note that the carriage return character can be executed normally. Of course, this is also a little interesting. We can fake the carriage return character in most text editors, at the end of the notebook, you can think that there is a carriage return character.

After a series of tossing, I found that the ^ character may cause memory leakage at the end of the file, or cause the command prompt to crash (specifically, command.com zookeeper .exe program ), I also found that special batch processing files (and their sequences) may cause some interesting phenomena. Further investigation guides me to see if other people have encountered similar situations, a Stack Overflow question where a user noted a memory leak (in the Stack Overflow question, a user indicates memory leakage) the topic other interesting behaviors with the caret at the EOF on SS64.com (an interesting phenomenon caused by carriage return at the end of the file ). The above questions in Stack Oveflow help me confirm that this is not an infinite loop type, but I have not explained exactly what it is, most of the content in the SS64.com topic is about making the command prompt crash in various aspects, but the principle is not explained.

Naturally, I have a question in my mind. How did it happen? How did it happen? Can this situation be exploited? The answer is complicated, but the solution is simple (at least it looks simple). I found some combinations of spoofed batch processing files that can cause memory leakage. Whether it is fast or slow depends on what the batch processing file you put into (not how many characters are inserted, but the pipeline sequence and the number of lines in length), whether it is a command prompt crash or memory leakage, the parsing code has always been resident in a single thread, so the CPU usage has been increasing (the average usage of Single-core CPU reaches 98%)

 

 

0x02

It is easy to crash the command prompt. A batch processing file without line breaks only needs to include ^ & ^ (or ^ | ^), which is enough to cause the command prompt to have a 0xC00000FD error, this is because of the infinite recursive stack/frame leakage. This replays the "Infinite Loop" scenario, but does not perfectly explain the memory leakage (or why this infinite loop will cause a crash, I started to use some of the simplest methods to generate a memory leak. It turns out that, A 2-byte batch processing file consumes the entire CPU and memory (although the speed is too slow ,~ 8 k/5S on a 2.2 GHz i7)

0x03

The batch file I used to test contains the following hexadecimal bytes

0x01 0x5E

0X5E is the unsigned symbol (^), and 0X01 is the Ascll code starting with the title. The first HEX Code has no danger in this BUG because it cannot be NULL (0X00), \ r, |, or & these characters will cause the batch processing file to exit through normal channels (that is, 'invalidcommand detected '). I use 0X01 to verify that it does not have a valid command (or display relevant characters), which leads to this BUG. A 2-byte batch file contains a simple ^.

In other tests, I found that adding ^ nul <^ at the end of the batch processing file is the fastest and easiest way to consume CPU.

After several random runs, please note that this will consume 64-bit CPU quickly. It took only 20 S to eat my 14 gb ram (a total of 16 GB, quad core I7 and hyper-Threading Technology), and finally I had to restart my computer. Run this quick version on a 32-bit system. Although the 32-bit system has a 2 GB limit, the command parser will soon end the task due to insufficient memory. It does not cause the command prompt to crash. On the contrary, it seems that there is a detection mechanism to protect memory allocation when it cannot directly terminate the batch processing process.

0x04

Note that although these batch processing exploits can be linked to each other, they are on a 32-bit operating system (assuming they only have 4 gb ram and do not have physical extended memory ), run the following command to construct DoS: cmd eat_mem.bat | eat_mem.bat. This will start two command interpreters, each of which will consume 2 GB.

Another interesting change is the connection between crashed batch processing files. For example, assume there is a file named crash. bat contains the "crash exploitation" (^ & ^) we mentioned above. You can do this: cmd crash. bat | crash. bat then pay attention to some interesting behaviors that will output cmd crash due to parsing errors. bat

 

The error wrote to a non-existent pipe occurs when you try to stop using CTRL + C. Interestingly, it still allows you to execute commands, such as typing notepad, hitting the carriage return, and then starting the notepad program. For a while, I think there is a high possibility of pipeline hijacking, but I don't get any answer (there are many ways to use it)

 

0x05

As mentioned in Stack Overflow, many ^ characters are in a row, which consumes a lot of memory (except the quick version I found, I found that the "President" actually brought some interesting results in this BUG. If there is a ^ character at the end of a 8192-byte batch file, this BUG will not succeed... As long as the sum is lower than or higher than 8192, the BUG is true. The more bytes a string contains, the faster memory consumption.

It should be noted that the file size has nothing to do with this BUG, because it can be put in any harmless file. For a test, I put the "quick" version (^ nul <^) into a code that I have left for compilation. This compilation script can be used for recursive calls and other functions, only 21KB. (Please allow me to compile these items) Put this line to the end of the file, allow me to run the compilation script normally, and it is completely normal, but when it hits a BUG, the CPU went crazy and quickly swallowed up my memory.

If I am a humble software engineer and give a "simple" Compilation script (randomly called in this BUG: eof), I will not think more if my CPU turns crazy, if I didn't notice the task manager, I wouldn't see that my RAM would be eaten so quickly and then restarted (this TMD is not fun)

0x06

Since then, I have decided to perform some advanced checks to see what happened to the command prompt. I opened Process Explorer and Procmon tools to detect the Process and system (through Procmon tools) what happened. Procmon confirms that this 8 K (more accurately, 8192 bytes) leakage will call ReadFile A 8191-byte buffer, and Process Explorer confirms that it will call the core of ReadFile. However, I am not very sure how the batch processing file is read and obtained.

This BUG also allows the batch processing file to be modified at runtime and parsed again. Note that the content can be modified and the command will handle it, but I noticed that unless there are a large number of other commands (more specifically, after the ^ symbol)

This batch processing attracted me to think about programming. My first attempt was a simple C program.

System ("crash. bat"); call the batch file containing the batch file of example and example, and start a single cmd.exe process. Then, my program returns to control and crashes (as expected ). After all, I switched to a simple Memory Leak Program (containing only one worker and then running the program again). Then, I can run the program. However, when I press CTRL + C to break the process, then I can return to my program control, so that I have to use the process of the task manager mongo.exe. I also try to directly use the file in the Program (in other words, it is to call system ("^ nul <^");) but get a valid result (in this case, it is legal, it means that the command is regarded as invalid by the parser.) I try to hook the program changes, or use the stack/frame overflow error, but it is caused by the plug-in. EXE parser itself, some exploits that are too obvious and not So Easy as it looks. In this process, I decided to open the cmd.exe program to detect the cause of a better condition.