Apache Commons IO: Possible denial of service attack on untrusted input to XmlStreamReader
Out-of-bounds Write vulnerability in Apache Commons Configuration.
Affected versions:
- Apache Commons Configuration 2.0 before 2.10.1
References:
https://www.cve.org/CVERecord?id=CVE-2024-29131 https://issues.apache.org/jira/browse/CONFIGURATION-840
SnapCenter versions 4.8 through 4.9 are susceptible to a vulnerability which may allow an authenticated SnapCenter Server user to become an admin user on a remote system where a SnapCenter plug-in has been installed.
SnapCenter versions 3.x and 4.x prior to 4.9 are susceptible to a vulnerability which may allow an authenticated unprivileged user to gain access as an admin user.
A vulnerability exists in curl <7.87.0 HSTS check that could be bypassed to trick it to keep using HTTP. Using its HSTS support, curl can be instructed to use HTTPS instead of using an insecure clear-text HTTP step even when HTTP is provided in the URL. However, the HSTS mechanism could be bypassed if the host name in the given URL first uses IDN characters that get replaced to ASCII counterparts as part of the IDN conversion. Like using the character UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) instead of the common ASCII full stop (U+002E) .. Then in a subsequent request, it does not detect the HSTS state and makes a clear text transfer. Because it would store the info IDN encoded but look for it IDN decoded.
SnapCenter versions prior to 4.7 shipped without Content Security Policy (CSP) implemented which could allow certain types of attacks that otherwise would be prevented.
Description Invalid HTTP/2 requests (for example, invalid URIs) are incorrectly handled by writing a blocking error response directly from the selector thread. If the client manages to exhaust the HTTP/2 flow control window, or TCP congest the connection, the selector thread will be blocked trying to write the error response. If this is repeated for all the selector threads, the server becomes unresponsive, causing the denial of service.
Impact A malicious client may render the server unresponsive.
Patches The fix is available in Jetty versions 9.4.47. 10.0.10, 11.0.10.
Workarounds No workaround available within Jetty itself. One possible workaround is to filter the requests before sending them to Jetty (for example in a proxy)
For more information If you have any questions or comments about this advisory: Email us at security@webtide.com.
A use of incorrectly resolved name vulnerability fixed in 7.83.1 might remove the wrong file when --no-clobber is used together with --remove-on-error.
Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. We recommend upgrading to version 3.15.0 or greater.
Due to the formatting logic of the "console.table()" function it was not safe to allow user controlled input to be passed to the "properties" parameter while simultaneously passing a plain object with at least one property as the first parameter, which could be "proto". The prototype pollution has very limited control, in that it only allows an empty string to be assigned to numerical keys of the object prototype.Node.js >= 12.22.9, >= 14.18.3, >= 16.13.2, and >= 17.3.1 use a null protoype for the object these properties are being assigned to.
Internally libssl in OpenSSL calls X509verifycert() on the client side to verify a certificate supplied by a server. That function may return a negative return value to indicate an internal error (for example out of memory). Such a negative return value is mishandled by OpenSSL and will cause an IO function (such as SSLconnect() or SSLdohandshake()) to not indicate success and a subsequent call to SSLgeterror() to return the value SSLERRORWANTRETRYVERIFY. This return value is only supposed to be returned by OpenSSL if the application has previously called SSLCTXsetcertverifycallback(). Since most applications do not do this the SSLERRORWANTRETRYVERIFY return value from SSLgeterror() will be totally unexpected and applications may not behave correctly as a result. The exact behaviour will depend on the application but it could result in crashes, infinite loops or other similar incorrect responses. This issue is made more serious in combination with a separate bug in OpenSSL 3.0 that will cause X509verifycert() to indicate an internal error when processing a certificate chain. This will occur where a certificate does not include the Subject Alternative Name extension but where a Certificate Authority has enforced name constraints. This issue can occur even with valid chains. By combining the two issues an attacker could induce incorrect, application dependent behaviour. Fixed in OpenSSL 3.0.1 (Affected 3.0.0).
Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.26 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as unauthorized update, insert or delete access to some of MySQL Server accessible data.
External References:
http://www.oracle.com/security-alerts/cpuoct2021.html#AppendixMSQL
Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Windows). Supported versions that are affected are 8.0.25 and prior. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 7.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).
A flaw was found in curl. This flaw lies in the --ssl-reqd option or related settings in libcurl. Users specify this flag to upgrade to TLS when communicating with either IMAP, POP3 or a FTP server. An attacker controlling such servers could return a crafted response which could lead to curl client continue its operation without TLS encryption leading to data being transmitted in clear text over the network. The highest threat from this vulnerability is to data confidentiality.
libcurl-using applications can ask for a specific client certificate to be used in a transfer. This is done with the CURLOPTSSLCERT option (--cert with the command line tool).When libcurl is built to use the macOS native TLS library Secure Transport, an application can ask for the client certificate by name or with a file name - using the same option. If the name exists as a file, it will be used instead of by name.If the appliction runs with a current working directory that is writable by other users (like /tmp), a malicious user can create a file name with the same name as the app wants to use by name, and thereby trick the application to use the file based cert instead of the one referred to by name making libcurl send the wrong client certificate in the TLS connection handshake.
ecverify in kdc/kdcpreauthec.c in the Key Distribution Center (KDC) in MIT Kerberos 5 (aka krb5) before 1.18.4 and 1.19.x before 1.19.2 allows remote attackers to cause a NULL pointer dereference and daemon crash. This occurs because a return value is not properly managed in a certain situation.
A use-after-free flaw was found in the way curl handled TLS session data. The curl versions using the OpenSSL library as their TLS backend could use freed memory after TLS session renegotiation was performed by the OpenSSL library. A malicious TLS server could use this flaw to crash or, possibly, execute arbitrary code with the privileges of a client application using the curl library.
Highcharts JS is a JavaScript charting library based on SVG. In Highcharts versions 8 and earlier, the chart options structure was not systematically filtered for XSS vectors. The potential impact was that content from untrusted sources could execute code in the end user's browser. The vulnerability is patched in version 9. As a workaround, implementers who are not able to upgrade may apply DOMPurify recursively to the options structure to filter out malicious markup.
Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Parser). Supported versions that are affected are 5.7.29 and prior and 8.0.19 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in takeover of MySQL Server. CVSS 3.1 Base Score 7.2 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H).
Impact When using SSL/TLS with Jetty, either with HTTP/1.1, HTTP/2, or WebSocket, the server may receive an invalid large (greater than 17408) TLS frame that is incorrectly handled, causing CPU resources to eventually reach 100% usage.
Workarounds
The problem can be worked around by compiling the following class: java package org.eclipse.jetty.server.ssl.fix6072;
import java.nio.ByteBuffer; import javax.net.ssl.SSLEngine; import javax.net.ssl.SSLEngineResult; import javax.net.ssl.SSLException; import javax.net.ssl.SSLHandshakeException;
import org.eclipse.jetty.io.EndPoint; import org.eclipse.jetty.io.ssl.SslConnection; import org.eclipse.jetty.server.Connector; import org.eclipse.jetty.server.SslConnectionFactory; import org.eclipse.jetty.util.BufferUtil; import org.eclipse.jetty.util.annotation.Name; import org.eclipse.jetty.util.ssl.SslContextFactory;
public class SpaceCheckingSslConnectionFactory extends SslConnectionFactory { public SpaceCheckingSslConnectionFactory(@Name("sslContextFactory") SslContextFactory factory, @Name("next") String nextProtocol) { super(factory, nextProtocol); }
@Override protected SslConnection newSslConnection(Connector connector, EndPoint endPoint, SSLEngine engine) { return new SslConnection(connector.getByteBufferPool(), connector.getExecutor(), endPoint, engine, isDirectBuffersForEncryption(), isDirectBuffersForDecryption()) { @Override protected SSLEngineResult unwrap(SSLEngine sslEngine, ByteBuffer input, ByteBuffer output) throws SSLException { SSLEngineResult results = super.unwrap(sslEngine, input, output);
if ((results.getStatus() == SSLEngineResult.Status.BUFFERUNDERFLOW || results.getStatus() == SSLEngineResult.Status.OK && results.bytesConsumed() == 0 && results.bytesProduced() == 0) && BufferUtil.space(input) == 0) { BufferUtil.clear(input); throw new SSLHandshakeException("Encrypted buffer max length exceeded"); } return results; } }; } } This class can be deployed by: + The resulting class file should be put into a jar file (eg sslfix6072.jar) + The jar file should be made available to the server. For a normal distribution this can be done by putting the file into ${jetty.base}/lib + Copy the file ${jetty.home}/modules/ssl.mod to ${jetty.base}/modules + Edit the ${jetty.base}/modules/ssl.mod file to have the following section:
[lib] lib/sslfix6072.jar
+ Copy the file ${jetty.home}/etc/jetty-https.xml and${jetty.home}/etc/jetty-http2.xml to ${jetty.base}/etc + Edit files ${jetty.base}/etc/jetty-https.xml and ${jetty.base}/etc/jetty-http2.xml, changing any reference of org.eclipse.jetty.server.SslConnectionFactory to org.eclipse.jetty.server.ssl.fix6072.SpaceCheckingSslConnectionFactory. For example: xml <Call name="addIfAbsentConnectionFactory"> <Arg> <New class="org.eclipse.jetty.server.ssl.fix6072.SpaceCheckingSslConnectionFactory"> <Arg name="next">http/1.1</Arg> <Arg name="sslContextFactory"><Ref refid="sslContextFactory"/></Arg> </New> </Arg> </Call> + Restart Jetty
The Data::Validate::IP module through 0.29 for Perl does not properly consider extraneous zero characters at the beginning of an IP address string, which (in some situations) allows attackers to bypass access control that is based on IP addresses.
A flaw was found in nodejs. A denial of service is possible when the whitelist includes “localhost6”. When “localhost6” is not present in /etc/hosts, it is just an ordinary domain that is resolved via DNS over the network. If the attacker controls the victim's DNS server or can spoof its responses, the DNS rebinding protection can be bypassed by using the “localhost6” domain. As long as the attacker uses the “localhost6” domain, they can still apply the attack described in CVE-2018-7160.
An unspecified vulnerability in Oracle MySQL Server related to the InnoDB component could allow an authenticated attacker to cause no confidentiality impact, low integrity impact, and high availability impact.
The GitHub Security Lab team has identified potential security vulnerabilities in jquery.validation.
The project contains one or more regular expressions that are vulnerable to ReDoS (Regular Expression Denial of Service)
This issue was discovered and reported by GitHub team member @erik-krogh (Erik Krogh Kristensen).
A flaw was found in krb5. MIT Kerberos 5 allows unbounded recursion via an ASN.1-encoded Kerberos message because the lib/krb5/asn.1/asn1encode.c support for BER indefinite lengths lacks a recursion limit.
Impact On Unix like systems, the system's temporary directory is shared between all users on that system. A collocated user can observe the process of creating a temporary sub directory in the shared temporary directory and race to complete the creation of the temporary subdirectory. If the attacker wins the race then they will have read and write permission to the subdirectory used to unpack web applications, including their WEB-INF/lib jar files and JSP files. If any code is ever executed out of this temporary directory, this can lead to a local privilege escalation vulnerability.
Additionally, any user code uses of WebAppContext::getTempDirectory) would similarly be vulnerable.
Additionally, any user application code using the ServletContext attribute for the tempdir will also be impacted. See: https://javaee.github.io/javaee-spec/javadocs/javax/servlet/ServletContext.html#TEMPDIR
For example: java import java.io.File; import java.io.IOException; import javax.servlet.ServletContext; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse;
public class ExampleServlet extends HttpServlet { @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { File tempDir = (File)getServletContext().getAttribute(ServletContext.TEMPDIR); // Potentially compromised // do something with that temp dir } }
Example: The JSP library itself will use the container temp directory for compiling the JSP source into Java classes before executing them.
CVSSv3.1 Evaluation
This vulnerability has been calculated to have a CVSSv3.1 score of 7.8/10 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Patches Fixes were applied to the 9.4.x branch with: - https://github.com/eclipse/jetty.project/commit/53e0e0e9b25a6309bf24ee3b10984f4145701edb - https://github.com/eclipse/jetty.project/commit/9ad6beb80543b392c91653f6bfce233fc75b9d5f
These will be included in releases: 9.4.33, 10.0.0.beta3, 11.0.0.beta3
Workarounds
A work around is to set a temporary directory, either for the server or the context, to a directory outside of the shared temporary file system. For recent releases, a temporary directory can be created simple by creating a directory called work in the ${jetty.base} directory (the parent directory of the webapps directory). Alternately the java temporary directory can be set with the System Property java.io.tmpdir. A more detailed description of how jetty selects a temporary directory is below.
The Jetty search order for finding a temporary directory is as follows:
1. If the WebAppContext has a temp directory specified), use it. 2. If the ServletContext has the javax.servlet.context.tempdir attribute set, and if directory exists, use it. 3. If a ${jetty.base}/work directory exists, use it (since Jetty 9.1) 4. If a ServletContext has the org.eclipse.jetty.webapp.basetempdir attribute set, and if the directory exists, use it. 5. Use System.getProperty("java.io.tmpdir") and use it.
Jetty will end traversal at the first successful step. To mitigate this vulnerability the directory must be set to one that is not writable by an attacker. To avoid information leakage, the directory should also not be readable by an attacker.
Setting a Jetty server temporary directory.
Choices 3 and 5 apply to the server level, and will impact all deployed webapps on the server.
For choice 3 just create that work directory underneath your ${jetty.base} and restart Jetty.
For choice 5, just specify your own java.io.tmpdir when you start the JVM for Jetty.
shell [jetty-distribution]$ java -Djava.io.tmpdir=/var/web/work -jar start.jar
Setting a Context specific temporary directory.
The rest of the choices require you to configure the context for that deployed webapp (seen as ${jetty.base}/webapps/<context>.xml)
Example (excluding the DTD which is version specific):
xml <Configure class="org.eclipse.jetty.webapp.WebAppContext"> <Set name="contextPath"><Property name="foo"/></Set> <Set name="war">/var/web/webapps/foo.war</Set> <Set name="tempDirectory">/var/web/work/foo</Set> </Configure>
References - https://github.com/eclipse/jetty.project/issues/5451 - CWE-378: Creation of Temporary File With Insecure Permissions - CWE-379: Creation of Temporary File in Directory with Insecure Permissions - CodeQL Query PR To Detect Similar Vulnerabilities
Similar Vulnerabilities
Similar, but not the same.
- JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - Google Guava - https://github.com/google/guava/issues/4011 - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824
For more information
The original report of this vulnerability is below:
On Thu, 15 Oct 2020 at 21:14, Jonathan Leitschuh <jonathan.leitschuh@gmail.com> wrote: Hi WebTide Security Team, I'm a security researcher writing some custom CodeQL queries to find Local Temporary Directory Hijacking Vulnerabilities. One of my queries flagged an issue in Jetty. https://lgtm.com/query/5615014766184643449/ I've recently been looking into security vulnerabilities involving the temporary directory because on unix-like systems, the system temporary directory is shared between all users. There exists a race condition between the deletion of the temporary file and the creation of the directory. java // ensure file will always be unique by appending random digits tmpDir = File.createTempFile(temp, ".dir", parent); // Attacker knows the full path of the file that will be generated // delete the file that was created tmpDir.delete(); // Attacker sees file is deleted and begins a race to create their own directory before Jetty. // and make a directory of the same name // SECURITY VULNERABILITY: Race Condition! - Attacker beats Jetty and now owns this directory tmpDir.mkdirs(); https://github.com/eclipse/jetty.project/blob/1b59672b7f668b8a421690154b98b4b2b03f254b/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebInfConfiguration.java#L511-L518 In several cases the parent parameter will not be the system temporary directory. However, there is one case where it will be, as the last fallback. https://github.com/eclipse/jetty.project/blob/1b59672b7f668b8a421690154b98b4b2b03f254b/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebInfConfiguration.java#L467-L468 If any code is ever executed out of this temporary directory, this can lead to a local privilege escalation vulnerability. Would your team be willing to open a GitHub security advisory to continue the discussion and disclosure there? https://github.com/eclipse/jetty.project/security/advisories This vulnerability disclosure follows Google's 90-day vulnerability disclosure policy (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. Cheers, Jonathan Leitschuh
Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DML). Supported versions that are affected are 8.0.21 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in takeover of MySQL Server.
External References:
https://www.oracle.com/security-alerts/cpuoct2020.html#AppendixMSQL
In Spring Framework versions 5.2.0 - 5.2.8, 5.1.0 - 5.1.17, 5.0.0 - 5.0.18, 4.3.0 - 4.3.28, and older unsupported versions, the protections against RFD attacks from CVE-2015-5211 may be bypassed depending on the browser used through the use of a jsessionid path parameter.
Last updated 24 July 2024
Last updated 24 July 2024