1 Patch Analysis

The vulnerability can be found on Red Hat Bugzilla.

https://bugzilla.redhat.com/show_bug.cgi?id=1463199

The method of fixing the vulnerability is submitted on GitHub.

https://github.com/apache/httpd/commit/672187c168b94b562d8065e08e2cad5b00cdd0e3

The new code differs from the old code as follows:

The fix method is simple. That is, add the check on the return value of the h2_request_rcreate function. It is officially recommended that you upgrade the system to 2.4.26 to fix the vulnerability.

2 Vulnerability Cause

The vulnerable server code is downloaded from https://archive.apache.org/dist/httpd/httpd-2.4.25.tar.gz. The code is analyzed together with the patch to locate the cause.

The h2_stream_set_request_rec function calls h2_request_rcreat to create an HTTP2.0 request (req data structure). When h2_request_rcreat fails to be executed, the req is empty. In this case, the req is directly dereferenced in the log function ap_log_rerror. As a result, the server process crashes.

The h2_request_rcreate function is checked. It is found that req is set to 0 first. If any of the four variables, namely, r->method, scheme, r->hostname, and path, is NULL, an error is returned. If req is still 0, the server process crashes.

Which one of the four variables is NULL? The scheme variable is ruled out because it is checked and then assigned a value. path is parsed from r->parsed_uri. The apr_uri_unparse function is used multiple times, and it is believed that path is not NULL. The r-method field is the method of saving the request and is mandatory in the HTTP request. Therefore, this field should not be NULL. Only r->hostname, which is used to store the host name (domain name) of the request, may be NULL.

In an HTTP request, the host name can be saved in two places.

The request path is represented by a complete URL, which contains a host name. For example, in GET http://www.example.com/ HTTP/1.1, the host name is www.example.com. The server parses the host name in the ap_parse_uri function.

A host request header can also contains the host name, for example:

GET / HTTP/1.1

Host: www.example.com

The server parses the host name in the fix_hostname function.

The ap_parse_uri and fix_hostname functions are audited. It is found that r->hostname is NULL if the request does not contain a host header field.However, the server also considers this situation and performs the following judgment in the ap_read_request function:

Logic: If one of the following two conditions is met:

l   The value of r->hostname is NULL, and the requested HTTP version is 1.1 or later.

l   The host header field is not included, and the requested HTTP version is 1.1.

A 400 (Bad Request) status code is immediately returned, and the vulnerability is not triggered. As described in section 14.23 of RFC 2616 (HTTP/1.1), an HTTP/1.1 request must contain the Host header field.

Developers seem to forget HTTP/1.0. Although HTTP/1.0 and HTTP/1.1 processes are the same, the Host header field is not mandatory in HTTP/1.0 requests. That is, HTTP/1.0 requests may not contain any Host header field. The program can execute the code according to the process before finally executing the h2_stream_set_request_rec function. In this case, r->hostname is NULL, which triggers the vulnerability.

3 Vulnerability POC and Exploit

The preceding analysis indicates that the vulnerability can be exploited when the following conditions are met:

l   The server supports HTTP/2.

l   The request is an HTTP/1.0 request.

l   The request does not contain the Host header field.

l   Server configuration is as follows:

The HTTP/2 function is enabled on the server, and the default site configuration of Apache is used. mod_http2.so: is first loaded in the configuration file.

Then, the following configuration is added, and Apache httpd is restarted:

POC

During the prove of concept (POC), the apache httpd service on a single process is started to verify the effect caused by process crash.

It works. Then return to the welcome page.

The constructed POC is sent through burpsuite.

No response is returned before the timer times out. Meanwhile, the httpd process on the server crashes.

Another attempt to access the server is made, but the page cannot be accessed.

Vulnerability Exploit

As described earlier, we have exploited the vulnerability on a single process to prove how the Apache server is terminated unexpectedly.Generally, multiple worker processes are started when the Apache server is started.

When a worker process crashes, the Apache server automatically starts a new worker process. How does a hacker exploit this vulnerability to attack the server in a real network environment?

We attempt to work out a multi-thread program (with 100 concurrent threads) and initiate multiple malformed requests to cause frequent worker crashes so that the Apache server is kept busy in allocating worker processes.

Requests initiated when scripts are running:

After the requests are initiated, we find that no special concurrent connection is required to make the server enter the denial of service (DoS) state.

4 Vulnerability Impact

In the Apache vulnerability notice, only the httpd 2.4.25 server is affected by this vulnerability. However, WeiRanLabs tests find that all httpd servers starting from 2.4.17 are crashed by the attack using POC, and the httpd server supports HTTP 2.0 starting from 2.4.17. Therefore, this vulnerability affects all httpd versions that support HTTP 2.0. WeiRanLabs strongly recommends that you update the server to 2.4.26.

The code in 2.4.25 differs from that in earlier versions. For example, the h2_request_rwrite function in 2.4.17 is as follows:

After a POC attack is suffered, r->hostname is NULL, and therefore req->authority also becomes NULL. ap_strchr_c is defined by the following macro:

In the preceding function, the first parameter that calls strchr is NULL, causing process crashes.

5 Summary

Multiple vulnerabilities have been fixed in Apache 2.4.26. It is widely believed that these vulnerabilities are difficult to exploit. WeiRan Labs analyzes and attempts to exploit some vulnerabilities and finds that the vulnerabilities can cause enormous impacts, especially on high-value sites.

Some methods discussed in this document may cause DoS and affect services on the target network. Therefore, do not apply the methods to the target network. WeiRan Labs are not liable for the consequences.

Your comments and suggestions are welcome. Please feel free to contact us at weiran.labs@huawei.com or WeChat account WeiRanLabs.