HTTP/2 Rapid reset attack The HTTP/2 protocol allows clients to indicate to the server that a previous stream should be canceled by sending a RSTSTREAM frame. The protocol does not require the client and server to coordinate the cancellation in any way, the client may do it unilaterally. The client may also assume that the cancellation will take effect immediately when the server receives the RSTSTREAM frame, before any other data from that TCP connection is processed.
Abuse of this feature is called a Rapid Reset attack because it relies on the ability for an endpoint to send a RSTSTREAM frame immediately after sending a request frame, which makes the other endpoint start working and then rapidly resets the request. The request is canceled, but leaves the HTTP/2 connection open.
The HTTP/2 Rapid Reset attack built on this capability is simple: The client opens a large number of streams at once as in the standard HTTP/2 attack, but rather than waiting for a response to each request stream from the server or proxy, the client cancels each request immediately.
The ability to reset streams immediately allows each connection to have an indefinite number of requests in flight. By explicitly canceling the requests, the attacker never exceeds the limit on the number of concurrent open streams. The number of in-flight requests is no longer dependent on the round-trip time (RTT), but only on the available network bandwidth.
In a typical HTTP/2 server implementation, the server will still have to do significant amounts of work for canceled requests, such as allocating new stream data structures, parsing the query and doing header decompression, and mapping the URL to a resource. For reverse proxy implementations, the request may be proxied to the backend server before the RSTSTREAM frame is processed. The client on the other hand paid almost no costs for sending the requests. This creates an exploitable cost asymmetry between the server and the client.
Multiple software artifacts implementing HTTP/2 are affected. This advisory was originally ingested from the swift-nio-http2 repo advisory and their original conent follows.
swift-nio-http2 specific advisory swift-nio-http2 is vulnerable to a denial-of-service vulnerability in which a malicious client can create and then reset a large number of HTTP/2 streams in a short period of time. This causes swift-nio-http2 to commit to a large amount of expensive work which it then throws away, including creating entirely new Channels to serve the traffic. This can easily overwhelm an EventLoop and prevent it from making forward progress.
swift-nio-http2 1.28 contains a remediation for this issue that applies reset counter using a sliding window. This constrains the number of stream resets that may occur in a given window of time. Clients violating this limit will have their connections torn down. This allows clients to continue to cancel streams for legitimate reasons, while constraining malicious actors.
Last updated 24 July 2024
A flaw was found in NodeJS. The issue occurs in the Node.js rebinding protector for --inspect that still allows invalid IP addresses, specifically, the octal format. This flaw allows an attacker to perform DNS rebinding and execute arbitrary code.
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed a malicious certificate or for an application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the . character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service).
In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.
OpenSSL versions 3.0.0 to 3.0.6 are vulnerable to this issue.
All versions of the v18.x and v19.x releases lines.
A vulnerability was found in NodeJS due to the llhttp parser in the HTTP module incorrectly handling multi-line Transfer-Encoding headers. This issue can lead to HTTP Request Smuggling (HRS). This flaw allows a remote attacker to send a specially crafted HTTP request to the server and smuggle arbitrary HTTP headers, causing web cache poisoning, and conducting XSS attacks.
A vulnerability was found in NodeJS due to improper validation of HTTP requests. The llhttp parser in the http module does not correctly parse and validate Transfer-Encoding headers. This issue can lead to HTTP Request Smuggling (HRS), causing web cache poisoning, and conducting XSS attacks.
A OS Command Injection vulnerability exists in Node.js versions <14.20.0, <16.20.0, <18.5.0 due to an insufficient IsAllowedHost check that can easily be bypassed because IsIPAddress does not properly check if an IP address is invalid before making DBS requests allowing rebinding attacks.
A vulnerability was found in NodeJS due to the llhttp parser in the http module not strictly using the CRLF sequence to delimit HTTP requests. This issue can lead to HTTP Request Smuggling (HRS). This flaw allows an attacker to send a specially crafted HTTP request to the server and smuggle arbitrary HTTP headers, causing web cache poisoning, and conducting XSS attacks.
A vulnerability was found in NodeJS due to improper validation of HTTP requests. The llhttp parser in the HTTP module in Node.js does not correctly handle header fields that are not terminated with CLRF. This issue may result in HTTP Request Smuggling. This flaw allows a remote attacker to send a specially crafted HTTP request to the server and smuggle arbitrary HTTP headers.
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution.
Many platforms implement stack overflow protections which would mitigate against the risk of remote code execution. The risk may be further mitigated based on stack layout for any given platform/compiler.
Pre-announcements of CVE-2022-3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors described above have led this to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible.
In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.
A vulnerability was found in NodeJS due to weak randomness in the WebCrypto keygen within the SecretKeyGenTraits::DoKeyGen() in src/crypto/cryptokeygen.cc. Node.js made calls to EntropySource() in SecretKeyGenTraits::DoKeyGen(). However, it does not check the return value and assumes the EntropySource() always succeeds, but it can and sometimes will fail. This flaw allows a remote attacker to decrypt sensitive information.
A cryptographic vulnerability exists on Node.js on linux in versions of 18.x prior to 18.40.0 which allowed a default path for openssl.cnf that might be accessible under some circumstances to a non-admin user instead of /etc/ssl as was the case in versions prior to the upgrade to OpenSSL 3.
Code injection and privilege escalation through Linux capabilities
Last updated 24 July 2024
Integrity checks according to experimental policies can be circumvented (Medium)
A vulnerability in Node.js HTTP servers allows an attacker to send a specially crafted HTTP request with chunked encoding, leading to resource exhaustion and denial of service (DoS).
A cryptographic vulnerability exists in Node.js <19.2.0, <18.14.1, <16.19.1, <14.21.3 that in some cases did does not clear the OpenSSL error stack after operations that may set it. This may lead to false positive errors during subsequent cryptographic operations that happen to be on the same thread. This in turn could be used to cause a denial of service.
A privilege escalation vulnerability exists in Node.js <19.6.1, <18.14.1, <16.19.1 and <14.21.3 that made it possible to bypass the experimental Permissions (https://nodejs.org/api/permissions.html) feature in Node.js and access non authorized modules by using process.mainModule.require(). This only affects users who had enabled the experimental permissions option with --experimental-policy.
Last updated 24 July 2024
A vulnerability has been identified in the Node.js (.msi version) installation process, specifically affecting Windows users who install Node.js using the .msi installer. This vulnerability emerges during the repair operation, where the "msiexec.exe" process, running under the NT AUTHORITY\SYSTEM context, attempts to read the %USERPROFILE% environment variable from the current user's registry.
The issue arises when the path referenced by the %USERPROFILE% environment variable does not exist. In such cases, the "msiexec.exe" process attempts to create the specified path in an unsafe manner, potentially leading to the creation of arbitrary folders in arbitrary locations.
The severity of this vulnerability is heightened by the fact that the %USERPROFILE% environment variable in the Windows registry can be modified by standard (or "non-privileged") users. Consequently, unprivileged actors, including malicious entities or trojans, can manipulate the environment variable key to deceive the privileged "msiexec.exe" process. This manipulation can result in the creation of folders in unintended and potentially malicious locations.
It is important to note that this vulnerability is specific to Windows users who install Node.js using the .msi installer. Users who opt for other installation methods are not affected by this particular issue.
A privilege escalation vulnerability exists in the experimental policy mechanism in all active release lines: 16.x, 18.x and, 20.x. The use of the deprecated API process.binding() can bypass the policy mechanism by requiring internal modules and eventually take advantage of process.binding('spawnsync') run arbitrary code, outside of the limits defined in a policy.json file. Please note that at the time this CVE was issued, the policy is an experimental feature of Node.js.
Node.js could allow a remote attacker to bypass security restrictions, caused by the use of module.constructor.createRequire(). By sending a specially crafted request, an attacker could exploit this vulnerability to bypass the permission policy mechanism.
HackerOne: CVE-2023-32002 Node.js Module.load() policy Remote Code Execution Vulnerability
An untrusted search path vulnerability exists in Node.js. <19.6.1, <18.14.1, <16.19.1, and <14.21.3 that could allow an attacker to search and potentially load ICU data when running with elevated privileges.
A vulnerability has been discovered in Node.js, where the use of proto in process.mainModule.proto.require() can bypass the policy mechanism and require modules outside of the policy.json definition.
Node.js could allow a local attacker to gain elevated privileges on the system, caused by the DLL search order hijacking of providers.dll. By placing a specially crafted file, an attacker could exploit this vulnerability to escalate privileges.
A flaw was found in the fetch API in Node.js that did not prevent CRLF injection in the 'host' header. This issue could allow HTTP response splitting and HTTP header injection.