An HTTP request broke the website

Hello everyone, I’m Jay Chou, today I will show you a piece of magic code.

With these few lines of magic code, the website can actually crash. What is going on?

It is the following function, which reads the file data according to the start and end positions passed in:

char* Read(int fd, int start, int end) {
    unsigned int length = end - start + 1;
    if (length > 1024)
        return NULL;

    return ReadFile(fd, start, end);
}

The function only supports reading 1024 bytes at a time, so a judgment logic is added.

Now, please think about it, is there any problem with this function?

---think---

---Test---

---5---

---Second---

---Bell---

Think about it, suppose I call this function like this:

Read(0, 0, 4294967295);

What will happen?

You may have noticed that there is a very special parameter passed here. This number is very large at first glance, far exceeding 1024. It stands to reason that it will not pass the check inside the function, right?

But things are not so simple. This special number- 4294967295 , is the maximum range that a 32-bit unsigned integer can represent.

But please pay attention to the parameters of the Read function. start and end are int . When 4294967295 is passed to end, it will be interpreted as a signed integer, which is -1!

Now look at this line of code for calculating the length in the Read function:

unsigned int length = end - start + 1;

The result of the calculation is -1-0 + 1 = 0!

The result of length will be 0!

Naturally, it has escaped the following length check:

if (length > 1024)
    return NULL;

The above code is not just a hypothetical model, in fact, it once existed!

Its vulnerability number is: CVE-2015-1635 .

This is a vulnerability in IIS of Microsoft's Internet server. What's more, this vulnerability is located in the HTTP.sys driver that IIS handles HTTP requests.

As you know, the driver runs in the operating system kernel. Once the kernel driver executes abnormally, the consequences can range from a blue screen crash to the attacker's remote code execution and control of the server!

In the HTTP 1.1 version of the protocol, you can request or upload part of the specified resource through the Range field in the request header, for example, like this:

GET /bg-upper.png HTTP/1.1
User-Agent: curl/7.35.0
Host: 127.0.0.1:8180
Accept: */*
Range: bytes=0-10

The format of the Range field is as follows:

Range: bytes=start-end

In order to improve the performance of Microsoft IIS, the analysis of the HTTP protocol is implemented in the kernel driver HTTP.sys.

In the processing of the range field, there is the logic error at the beginning of our article. The difference is that the example above is a 32-bit integer version, and the real vulnerability of IIS is a problem caused by a 64-bit integer. The principle is the same.

By sending the corresponding HTTP request to the vulnerable IIS server, the target server can be blue screened, and a DOS-denial of service attack can be realized.

This attack method is- integer overflow attack.

Next, let's build an environment to verify it.

Set up an IIS7 Web server in the virtual machine:

The maximum number that can be represented by a 64-bit unsigned integer is: 18446744073709551615 . By sending a request containing the range parameter to the server, it is likely to cause the server to blue screen.

Use the artifact metasploit to exploit this vulnerability to launch an attack:

Looking at it now, the server is down:

Why is it very likely, not a certain blue screen? How to achieve stability and blue screen the server? This requires further understanding of this vulnerability in more detail.

In fact, the principle of this vulnerability is more complicated than the logic at the beginning of the article. Here is just a simple introduction. For more detailed information about this vulnerability, you can take a look at a technical analysis written by 360 Great God MJ0011 that year (PS: A bit hard-core, I have to read it several times if I want to understand it):

"MS15-034/CVE-2015-1635 HTTP Remote Code Execution Vulnerability Analysis"

https://blogs.360.cn/post/cve_2015_6135_http_rce_analysis.html