RHSA-2021:5134CriticalCVSS 9.8

Red Hat Security Advisory: Red Hat Fuse 7.10.0 release and security update

Published
December 14, 2021
Last Modified
August 4, 2026

🔗 CVE IDs covered (54)

📋 Description

CVE-2019-10744 — nodejs-lodash: prototype pollution in defaultsDeep function leading to modifying properties CVE-2019-12415 — poi: a specially crafted Microsoft Excel document allows attacker to read files from the local filesystem CVE-2020-2875 — mysql-connector-java: allows unauthenticated attacker with network access via multiple protocols to compromise MySQL Connectors which could result in unauthorized update, insert or delete CVE-2020-2934 — mysql-connector-java: allows unauthenticated attacker with network access via multiple protocols to compromise MySQL Connectors which could result in unauthorized update, insert or delete CVE-2020-9488 — log4j: improper validation of certificate with host mismatch in SMTP appender CVE-2020-11987 — batik: SSRF due to improper input validation by the NodePickerPanel CVE-2020-11988 — xmlgraphics-commons: SSRF due to improper input validation by the XMPParser CVE-2020-13943 — tomcat: Apache Tomcat HTTP/2 Request mix-up CVE-2020-13949 — libthrift: potential DoS when processing untrusted payloads CVE-2020-15522 — bouncycastle: Timing issue within the EC math library CVE-2020-17521 — groovy: OS temporary directory leads to information disclosure CVE-2020-17527 — tomcat: HTTP/2 request header mix-up CVE-2020-26217 — XStream: remote code execution due to insecure XML deserialization when relying on blocklists CVE-2020-26259 — XStream: arbitrary file deletion on the local host when unmarshalling CVE-2020-27218 — jetty: buffer not correctly recycled in Gzip Request inflation CVE-2020-27223 — jetty: request containing multiple Accept headers with a large number of "quality" parameters may lead to DoS CVE-2020-27782 — undertow: special character in query results in server errors CVE-2020-28491 — jackson-dataformat-cbor: Unchecked allocation of byte buffer can cause a java.lang.OutOfMemoryError exception CVE-2020-35510 — jboss-remoting: Threads hold up forever in the EJB server by suppressing the ack from an EJB client CVE-2021-3536 — wildfly: XSS via admin console when creating roles in domain mode CVE-2021-3597 — undertow: HTTP2SourceChannel fails to write final frame under some circumstances may lead to DoS CVE-2021-3629 — undertow: potential security issue in flow control over HTTP/2 may lead to DOS CVE-2021-3690 — undertow: buffer leak on incoming websocket PONG message may lead to DoS CVE-2021-20218 — fabric8-kubernetes-client: vulnerable to a path traversal leading to integrity and availability compromise CVE-2021-21290 — netty: Information disclosure via the local system temporary directory CVE-2021-21295 — netty: possible request smuggling in HTTP/2 due missing validation CVE-2021-21341 — XStream: allow a remote attacker to cause DoS only by manipulating the processed input stream CVE-2021-21342 — XStream: SSRF via crafted input stream CVE-2021-21343 — XStream: arbitrary file deletion on the local host via crafted input stream CVE-2021-21344 — XStream: Unsafe deserizaliation of javax.sql.rowset.BaseRowSet CVE-2021-21345 — XStream: Unsafe deserizaliation of com.sun.corba.se.impl.activation.ServerTableEntry CVE-2021-21346 — XStream: Unsafe deserizaliation of sun.swing.SwingLazyValue CVE-2021-21347 — XStream: Unsafe deserizaliation of com.sun.tools.javac.processing.JavacProcessingEnvironment NameProcessIterator CVE-2021-21348 — XStream: ReDoS vulnerability CVE-2021-21349 — XStream: SSRF can be activated unmarshalling with XStream to access data streams from an arbitrary URL referencing a resource in an intranet or the local host CVE-2021-21350 — XStream: Unsafe deserizaliation of com.sun.org.apache.bcel.internal.util.ClassLoader CVE-2021-21351 — XStream: allow a remote attacker to load and execute arbitrary code from a remote host only by manipulating the processed input stream CVE-2021-21409 — netty: Request smuggling via content-length header CVE-2021-22118 — spring-web: (re)creating the temporary storage directory could result in a privilege escalation within WebFlux application CVE-2021-22696 — cxf: OAuth 2 authorization service vulnerable to DDos attacks CVE-2021-23926 — xmlbeans: allowed malicious XML input may lead to XML Entity Expansion attack CVE-2021-27568 — json-smart: uncaught exception may lead to crash or information disclosure CVE-2021-28163 — jetty: Symlink directory exposes webapp directory contents CVE-2021-28164 — jetty: Ambiguous paths can access WEB-INF CVE-2021-28169 — jetty: requests to the ConcatServlet and WelcomeFilter are able to access protected resources within the WEB-INF directory CVE-2021-28170 — jakarta-el: ELParserTokenManager enables invalid EL expressions to be evaluate CVE-2021-29425 — apache-commons-io: Limited path traversal in Apache Commons IO 2.2 to 2.6 CVE-2021-30129 — mina-sshd-core: Memory leak denial of service in Apache Mina SSHD Server CVE-2021-30468 — CXF: Denial of service vulnerability in parsing JSON via JsonMapObjectReaderWriter CVE-2021-34428 — jetty: SessionListener can prevent a session from being invalidated breaking logout CVE-2021-37136 — netty-codec: Bzip2Decoder doesn't allow setting size restrictions for decompressed data CVE-2021-37137 — netty-codec: SnappyFrameDecoder doesn't restrict chunk length and may buffer skippable chunks in an unnecessary way CVE-2021-37714 — jsoup: Crafted input may cause the jsoup HTML and XML parser to get stuck CVE-2021-44228 — log4j-core: Remote code execution in Log4j 2.x when logs contain an attacker-controlled string value

🎯 Affected products1

  • Red Hat Fuse 7.10

✅ Remediation

Before applying the update, back up your existing installation, including all applications, configuration files, databases and database settings, and so on. Installation instructions are available from the Fuse 7.10.0 product documentation page: https://access.redhat.com/documentation/en-us/red_hat_fuse/7.10/ Workaround: The vulnerability is in the XSSFExportToXml util; avoid usage of this tool to mitigate the vulnerability. Workaround: Previous versions can set the system property mail.smtp.ssl.checkserveridentity to true to globally enable hostname verification for SMTPS connections. Workaround: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability. Workaround: Setting the `java.io.tmpdir` system environment variable to a directory that is exclusively owned by the executing user will fix this vulnerability for all operating systems and all Groovy versions. Users who cannot easily move to the fixed Groovy versions may wish to consider using the JDK’s Files#createTempDirectory method instead of the Groovy extension methods. Workaround: Depending on the version of XStream used there are various usage patterns that mitigate this flaw, though we would strongly recommend using the allow list approach if at all possible as there are likely more class combinations the deny list approach may not address. Allow list approach ```java XStream xstream = new XStream(); XStream.setupDefaultSecurity(xstream); xstream.allowTypesByWildcard(new String[] {"com.misc.classname"}) ``` Deny list for XStream 1.4.13 ```java xstream.denyTypes(new String[]{ "javax.imageio.ImageIO$ContainsFilter" }); xstream.denyTypes(new Class[]{ java.lang.ProcessBuilder.class }); ``` Deny list for XStream 1.4.7 -> 1.4.12 ```java xstream.denyTypes(new String[]{ "javax.imageio.ImageIO$ContainsFilter" }); xstream.denyTypes(new Class[]{ java.lang.ProcessBuilder.class, java.beans.EventHandler.class, java.lang.ProcessBuilder.class, java.lang.Void.class, void.class }); ``` Deny list for versions prior to XStream 1.4.7 ```java xstream.registerConverter(new Converter() { public boolean canConvert(Class type) { return type != null && (type == java.beans.EventHandler.class || type == java.lang.ProcessBuilder.class || type == java.lang.Void.class || void.class || type.getName().equals("javax.imageio.ImageIO$ContainsFilter") || Proxy.isProxy(type)); } public Object unmarshal(HierarchicalStreamReader reader, UnmarshallingContext context) { throw new ConversionException("Unsupported type due to security reasons."); } public void marshal(Object source, HierarchicalStreamWriter writer, MarshallingContext context) { throw new ConversionException("Unsupported type due to security reasons."); } }, XStream.PRIORITY_LOW); ``` Workaround: As recommended, use XStream's security framework to implement a whitelist for the allowed types. Users of XStream 1.4.14 who insist to use XStream default blacklist - despite that clear recommendation - can simply add two lines to XStream's setup code: xstream.denyTypes(new String[]{ "jdk.nashorn.internal.objects.NativeString" }); xstream.denyTypesByRegExp(new String[]{ ".*\\.ReadAllStream\\$FileStream" }); Users of XStream 1.4.13 who want to use XStream default blacklist can simply add three lines to XStream's setup code: xstream.denyTypes(new String[]{ "javax.imageio.ImageIO$ContainsFilter", "jdk.nashorn.internal.objects.NativeString" }); xstream.denyTypes(new Class[]{ java.lang.ProcessBuilder.class }); xstream.denyTypesByRegExp(new String[]{ ".*\\.ReadAllStream\\$FileStream" }); Users of XStream 1.4.12 to 1.4.7 who want to use XStream with a blacklist will have to setup such a list from scratch and deny at least the following types: javax.imageio.ImageIO$ContainsFilter, java.beans.EventHandler, java.lang.ProcessBuilder, jdk.nashorn.internal.objects.NativeString, java.lang.Void and void and deny several types by name pattern. xstream.denyTypes(new String[]{ "javax.imageio.ImageIO$ContainsFilter", "jdk.nashorn.internal.objects.NativeString" }); xstream.denyTypes(new Class[]{ java.lang.ProcessBuilder.class, java.beans.EventHandler.class, java.lang.ProcessBuilder.class, java.lang.Void.class, void.class }); xstream.denyTypesByRegExp(new String[]{ ".*\\$LazyIterator", "javax\\.crypto\\..*", ".*\\.ReadAllStream\\$FileStream" }); Users of XStream 1.4.6 or below can register an own converter to prevent the unmarshalling of the currently know critical types of the Java runtime. It is in fact an updated version of the workaround for CVE-2013-7285: xstream.registerConverter(new Converter() { public boolean canConvert(Class type) { return type != null && (type == java.beans.EventHandler.class || type == java.lang.ProcessBuilder.class || type.getName().equals("javax.imageio.ImageIO$ContainsFilter") || type.getName().equals("jdk.nashorn.internal.objects.NativeString") || type == java.lang.Void.class || void.class || Proxy.isProxy(type) || type.getName().startsWith("javax.crypto.") || type.getName().endsWith("$LazyIterator") || type.getName().endsWith(".ReadAllStream$FileStream")); } public Object unmarshal(HierarchicalStreamReader reader, UnmarshallingContext context) { throw new ConversionException("Unsupported type due to security reasons."); } public void marshal(Object source, HierarchicalStreamWriter writer, MarshallingContext context) { throw new ConversionException("Unsupported type due to security reasons."); } }, XStream.PRIORITY_LOW); Workaround: The issue can be mitigated by using HTTP/1.1 instead of AJP to proxy to the back-end. Workaround: Affected users are advised to update to Apache XMLBeans 3.0.0 or above, which fixes this vulnerability. Workaround: Applications should catch all Throwables within their SessionListener#sessionDestroyed() implementations. Workaround: For Log4j versions >=2.10 set the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true For Log4j versions >=2.7 and <=2.14.1 all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m For Log4j versions >=2.0-beta9 and <=2.10.0 remove the JndiLookup class from the classpath. For example: ``` zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class ``` On OpenShift 4 and in OpenShift Logging, the above mitigation can be applied by following the steps in this article: https://access.redhat.com/solutions/6578421 On OpenShift 3.11, mitigation to the affected Elasticsearch component can be applied by following the steps in this article: https://access.redhat.com/solutions/6578441

🔗 References (60)