• Skip to main content
  • Skip to secondary menu
  • Skip to primary sidebar
  • Skip to footer
NetScaler Blog

NetScaler Blog

Application delivery and security blog

Application delivery and security blog
  • Application delivery
  • Application and API security
  • Application modernization
  • Observability
  • News

NetScaler is not impacted by the HTTP/2 CONTINUATION flood DoS vulnerability

March 27, 2024 by Anil Shetty

IT worker on computer

On April 3, 2024, Bartek Nowotarski published a blog on HTTP/2 CONTINUATION flood that impacts multiple implementations of the HTTP/2 protocol. Please refer to this link for more details on the vulnerability. 

NetScaler is not impacted, and NetScaler software and platforms (SDX/MPX/VPX/BLX/CPX) are not vulnerable to the HTTP/2 CONTINUATION flood vulnerability that was reported. The default configuration of NetScaler software and platforms provides out-of-the-box mitigation against this vulnerability.

The NetScaler team conducted testing with a tool simulating the attack vector. We observed no operational issues with NetScaler device resources, including CPU and memory utilization, for the duration of the attack. 

Please refer to the product support matrix for supported releases.

NetScaler protects your applications from the HTTP/2 CONTINUATION flood vulnerability

An HTTP/2 virtual server configured on NetScaler to handle application traffic protects the applications from this vulnerability. The default configuration settings of the HTTP/2 protocol on NetScaler are sufficient to mitigate the exploit. No further tuning is necessary. 

Note: If you have modified either tcpBufParam -memlimit (parameter that applies to tcp buffer) or maxHeaderLen (parameter configured at http profile level) parameters from their default values, you may observe a variance in CPU/memory consumption on the NetScaler ADC if there is an attempted exploit of this vulnerability. Please contact Citrix technical support if you need further assistance with non-default values for these parameters.

Details on the HTTP/2 vulnerability

As per RFC9113: HTTP/2 (Section 4.3), the CONTINUATION frame (type=0x09) is used to continue a sequence of field block fragments. Any number of CONTINUATION frames can be sent, as long as the preceding frame is on the same stream and is a HEADERS, PUSH_PROMISE, or CONTINUATION frame without the END_HEADERS flag set. Typically, this frame is used to send large headers exceeding the initial header frame size.

Many HTTP/2 implementations do not properly handle CONTINUATION Frames connected to headers wherein header length limits are not properly enforced on the bytes received in HEADER and subsequent one or more CONTINUATION frames. These conditions can be leveraged by attackers to cause Denial of Service (DoS) attacks on web servers handling HTTP/2 protocol by exhausting CPU or memory or both depending on how HTTP/2 protocol is implemented.

An attacker can send a stream of CONTINUATION frames, and while they may be accumulated in a list, the frames may still get decompressed and decoded even after exceeding the maximum header length configured. Additionally, these frames can be specifically designed to cause CPU load with HPACK Huffman decoding and dynamic table evictions. Some implementations may crash as they may run out of memory when an attacker sends multiple connections with many headers (encapsulated in CONTINUATION frames) and then stay idle or drop.

FAQs

What is the impact of this vulnerability?

A malicious HTTP/2 client can connect to a server and send all necessary and legitimate frames. Subsequently, the malicious HTTP/2 client can open a new HTTP/2 stream by sending a HEADERS frame, followed by one or more CONTINUATION frames for the same stream, that do not carry the END_HEADERS flag which is used to indicate that the HTTP header is complete. This pattern is replicated across multiple connections. 

This causes resource exhaustion at the server level as a result of the processing required to decompress and process the headers, as well as memory consumption resulting from the allocation to store the headers. Eventually, this may cause the server to crash leading to a denial of service (DoS).

Have DoS attacks been observed?

Currently, we have not observed incidents of DoS attacks as a result of this vulnerability on NetScaler devices.

Which protocols are impacted by this vulnerability?

Many implementations of the HTTP/2 protocol from multiple vendors are impacted. 

Is HTTP/2 enabled by default in NetScaler?

HTTP/2 is not enabled by default. It must be specifically enabled on an HTTP profile.

How can I tell if HTTP/2 is being used on a specific NetScaler ADC?

You can check if HTTP/2 is being used by examining all the HTTP Profiles in the configuration utility under System → Profiles → HTTP Profiles. If the HTTP/2 checkbox is checked in any of the profiles, then HTTP/2 may be in use if it is bound to a virtual server.

From the CLI, you can run the following command:

show run | grep  “http2 ENABLED”

Similarly, if HTTP/2 is found to be enabled in an HTTP profile, you will need to check if it is bound to any of your virtual servers.

Counters that can be monitored to check if the system is under a HTTP/2 CONTINUATION Frame attack

 http2_err_hdr_size_allowed_max

  • Indicates the number of headers received that exceeds the configured max header size – Possible indication of an attempt to attack using maximum header size

 http2_tot_continuation_frames_rcvd

  • Number of HTTP/2 continuation frames received – Indicates possible HTTP/2 CONTINUATION flood attack if the number of CONTINUATION frames are unusually high

http2_err_invalid_continuation_frame

  • Number of times NetScaler received the HTTP/2 CONTINUATION frame when it was not expecting to receive such frames 

 mem_err_tcpbuffpages_allocfailed

  • Number of times the TCP buffer allocation failed – Indicates that the TCP buffer used for handling HTTP/2 CONTINUATION frames are full; most likely counter to monitor for possible attack indication. 

Support 

If you require technical assistance with this issue, please contact Citrix Technical Support. 

Categories: Application and API security Tagged With: Application security, NetScaler news

Primary Sidebar

Popular posts

NetScaler Next-Gen API

Introducing NetScaler Next-Gen API: The declarative API for application developers 

June 17, 2024

Terraform provider for NetScaler SDX

Introducing the Terraform provider for NetScaler SDX

May 30, 2024

NetScaler now accepting GitHub community contributions

May 2, 2024

Introducing NetScaler CPX Express: A DevOps-friendly, free Kubernetes ingress proxy 

March 28, 2024

NetScaler: The power of one

NetScaler: The power of one

March 5, 2024

New utility converts NetScaler configurations into IaC for greater automation

New utility converts NetScaler configurations into IaC for greater automation

April 3, 2025

NetScaler 13.1-FIPS achieves NDcPP certification from NIAP and the CCCS

NetScaler 13.1-FIPS achieves NDcPP certification

February 27, 2025

CVE-2024-12284: High-severity security update for NetScaler Console

CVE-2024-12284: High-severity security update for NetScaler Console

February 18, 2025

Footer

Product resources

  • NetScaler editions
  • Integrations
  • Documentation
  • GitHub
  • Downloads

Support

  • Ask the community
  • Contact support

Company

  • NetScaler.com
  • About NetScaler
  • Contact us
  • Newsroom
  • Careers

  • Legal
  • Do not sell my personal information
  • Cookie preferences
© 2023 Cloud Software Group, Inc. All rights reserved.