📦 Bump versions of multiple dependencies to address vulnerabilities #72
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Lineaje has automatically created this pull request to resolve the following CVEs:
Software Foundation Apache XML Graphics Batik.This issue
affects Apache XML Graphics Batik: 1.16. On version 1.16, a
malicious SVG could trigger loading external resources by
default, causing resource consumption or in some cases even
information disclosure. Users are recommended to upgrade to
version 1.17 or later.
Software Foundation Apache XML Graphics Batik.This issue
affects Apache XML Graphics Batik: 1.16. On version 1.16, a
malicious SVG could trigger loading external resources by
default, causing resource consumption or in some cases even
information disclosure. Users are recommended to upgrade to
version 1.17 or later.
Apache XML Graphics allows an attacker to fetch external
resources. This issue affects Apache XML Graphics Batik
Bridge versions 1.14 and below.
attacker to run Java code from untrusted SVG via JavaScript.
This issue affects Apache XML Graphics prior to 1.16. Users
are recommended to upgrade to version 1.16.
through 2.25.2 does not perform TLS hostname verification of
the peer certificate, even when the
verifyHostName
configuration attribute or the
log4j2.sslVerifyHostName
system property is set to true. This issue may allow a
man-in-the-middle attacker to intercept or redirect log
traffic under the following conditions: * The attacker is
able to intercept or redirect network traffic between the
client and the log receiver. * The attacker can present a
server certificate issued by a certification authority
trusted by the Socket Appender’s configured trust store (or
by the default Java trust store if no custom trust store is
configured). Users are advised to upgrade to Apache Log4j
Core version 2.25.3, which addresses this issue. As an
alternative mitigation, the Socket Appender may be configured
to use a private or restricted trust root to limit the set of
trusted certificates.
Appender
security fix releases 2.3.2 and 2.12.4) are vulnerable to an
attack where an attacker with permission to modify the
logging configuration file can construct a malicious
configuration using a JDBC Appender with a data source
referencing a JNDI URI which can execute remote code. This
issue is fixed by limiting JNDI data source names to the java
protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2. #
Affected packages Only the
org.apache.logging.log4j:log4j-corepackage is directlyaffected by this vulnerability. The
org.apache.logging.log4j:log4j-apishould be kept at thesame version as the
org.apache.logging.log4j:log4j-corepackage to ensure compatability if in use. This issue does
not impact default configurations of Log4j2 and requires an
attacker to have control over the Log4j2 configuration, which
reduces the likelihood of being exploited.
2.12.3) did not protect from uncontrolled recursion from
self-referential lookups. This allows an attacker with
control over Thread Context Map data to cause a denial of
service when a crafted string is interpreted. This issue was
fixed in Log4j 2.17.0 and 2.12.3. # Affected packages Only
the
org.apache.logging.log4j:log4j-corepackage is directlyaffected by this vulnerability. The
org.apache.logging.log4j:log4j-apishould be kept at thesame version as the
org.apache.logging.log4j:log4j-corepackage to ensure compatability if in use.
remote code execution vulnerability via the ldap JNDI parser.
As per Apache's Log4j security
guide:
Apache Log4j2 <=2.14.1 JNDI features used in configuration,
log messages, and parameters do not protect against attacker
controlled LDAP and other JNDI related endpoints. An attacker
who can control log messages or log message parameters can
execute arbitrary code loaded from LDAP servers when message
lookup substitution is enabled. From log4j 2.16.0, this
behavior has been disabled by default. Log4j version 2.15.0
contained an earlier fix for the vulnerability, but that
patch did not disable attacker-controlled JNDI lookups in all
situations. For more information, see the
Updated advice for<br>version 2.16.0section of this advisory. # Impact Logginguntrusted or user controlled data with a vulnerable version
of Log4J may result in Remote Code Execution (RCE) against
your application. This includes untrusted data included in
logged errors such as exception traces, authentication
failures, and other unexpected vectors of user controlled
input. # Affected versions Any Log4J version prior to v2.15.0
is affected to this specific issue. The v1 branch of Log4J
which is considered End Of Life (EOL) is vulnerable to other
RCE vectors so the recommendation is to still update to
2.16.0 where possible. ## Security releases Additional
backports of this fix have been made available in versions
2.3.1, 2.12.2, and 2.12.3 ## Affected packages Only the
org.apache.logging.log4j:log4j-corepackage is directlyaffected by this vulnerability. The
org.apache.logging.log4j:log4j-apishould be kept at thesame version as the
org.apache.logging.log4j:log4j-corepackage to ensure compatability if in use. # Remediation
Advice ## Updated advice for version 2.16.0 The Apache
Logging Services team provided updated mitigation advice upon
the release of version 2.16.0, which disables JNDI by
default and completely removes support for message
lookups.
Even in version 2.15.0, lookups used in layouts to provide
specific pieces of context information will still recursively
resolve, possibly triggering JNDI lookups. This problem is
being tracked as
CVE-2021-45046.
More information is available on the GitHub Security
Advisory for
CVE-2021-45046.
Users who want to avoid attacker-controlled JNDI lookups but
cannot upgrade to 2.16.0 must ensure that no such lookups
resolve to attacker-provided data and ensure that the the
JndiLookup class is not
loaded.
Please note that Log4J v1 is End Of Life (EOL) and will not
receive patches for this issue. Log4J v1 is also vulnerable
to other RCE vectors and we recommend you migrate to Log4J
2.16.0 where possible.
CVE-2021-44228
in Apache Log4j 2.15.0 was incomplete in certain non-default
configurations. This could allow attackers with control over
Thread Context Map (MDC) input data when the logging
configuration uses a non-default Pattern Layout with either a
Context Lookup (for example, $${ctx:loginId}) or a Thread
Context Map pattern (%X, %mdc, or %MDC) to craft malicious
input data using a JNDI Lookup pattern resulting in a remote
code execution (RCE) attack. ## Affected packages Only the
org.apache.logging.log4j:log4j-corepackage is directlyaffected by this vulnerability. The
org.apache.logging.log4j:log4j-apishould be kept at thesame version as the
org.apache.logging.log4j:log4j-corepackage to ensure compatability if in use. # Mitigation Log4j
2.16.0 fixes this issue by removing support for message
lookup patterns and disabling JNDI functionality by default.
This issue can be mitigated in prior releases (< 2.16.0) by
removing the JndiLookup class from the classpath (example:
zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class). Log4j
2.15.0 restricts JNDI LDAP lookups to localhost by default.
Note that previous mitigations involving configuration such
as to set the system property
log4j2.formatMsgNoLookupstotruedo NOT mitigate this specific vulnerability.forgery, caused by improper input validation by the
NodePickerPanel. By using a specially-crafted argument, an
attacker could exploit this vulnerability to cause the
underlying server to make arbitrary GET requests.
You can merge this PR once the tests pass and the changes are reviewed.
Thank you for reviewing the update! 🚀