HTTP/2 SETTINGS frame bug and related registry keys

HTTP/2 protocol improves the performance and security of today’s digital world. It consists of several frames to carry requests between clients and servers. One of these frames is SETTINGS frame which may be used by attackers to increase CPU usage to 100% in IIS and eventually make the server unresponsive (Denial of Service – DoS).

In this post, we will discuss the root cause and the solution for this bug.

What is HTTP/2 SETTINGS frame?

It is part of the HTTP/2 request which contains 6 parameters to manage communication between peers. Here is how IETF HTTP Working Group explains the usage of this frame:

The SETTINGS frame (type=0x4) conveys configuration parameters that affect how endpoints communicate, such as preferences and constraints on peer behavior. The SETTINGS frame is also used to acknowledge the receipt of those parameters.

SETTINGS in Hypertext Transfer Protocol Version 2 (HTTP/2)
HTTP/2 SETTINGS frame
HTTP/2 SETTINGS frame (Source: IETF HTTP Working Group)

SETTINGS frame has the following parameters:

  • SETTINGS_HEADER_TABLE_SIZE: The maximum size of the header compression table used to decode header blocks
  • SETTINGS_ENABLE_PUSH: It can be used to disable server push
  • SETTINGS_MAX_CONCURRENT_STREAMS: The maximum number of concurrent streams that the sender will allow
  • SETTINGS_INITIAL_WINDOW_SIZE: The sender’s initial window size for stream-level flow control
  • SETTINGS_MAX_FRAME_SIZE: The size of the largest frame payload that the sender is willing to receive
  • SETTINGS_MAX_HEADER_LIST_SIZE: The maximum size of header list that the sender is prepared to accept

SETTINGS frame vulnerability

HTTP/2 protocol allows a client to specify any number of SETTINGS frames with any number of SETTINGS parameters. While IIS works on the request, it may cause high CPU load if there are too many frames and parameters to process.

Hopefully, Microsoft took action quickly to address this vulnerability before it is widely leveraged by the attackers.

Other factors such as using instances that are not thread-safe in your code
may cause high CPU load as well. Check out this post for the root cause and solution: High CPU load in IIS web server caused by HttpClient

Solution for SETTINGS frame bug

Microsoft released a security update to fix this bug. The update provides two registry keys to control maximum how many settings can be transferred in a frame and maximum how many settings can be transferred per minute. After installing the update, you should set these registry keys to a desired value based on your environment.

  • Http2MaxSettingsPerFrame (Registry path:
    Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters)
  • Http2MaxSettingsPerMinute (Registry path:
    Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters)

Make sure to restart your server after setting values to these keys. For more information, check out Microsoft Support page.

I recommend setting both of them to 256 but these values are highly dependent on the individual environment. There is currently no official formula to calculate optimum values.

Unfortunately, there is also no performance counters to monitor the count of SETTINGS frames and parameters. Therefore, you may need to dive deep in HttpQueryServiceConfiguration() API or a netsh helper to develop a script for monitoring these values.

HTTP protocol defines errors with status codes. One of them is 503 (Service Unavailable). If you have come across this error, check this post out for step-by-step solution: HTTP 503 Service Unavailable (Application pool has been disabled)

Spread the word!

Leave a Reply

Your email address will not be published. Required fields are marked *