RHSA-2021:3140MediumCVSS 9.8

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

Published
August 11, 2021
Last Modified
August 15, 2026

🔗 CVE IDs covered (43)

CVE-2021-27568 →CVE-2021-27906 →CVE-2019-20445 →CVE-2020-1935 →CVE-2020-10714 →CVE-2020-13936 →CVE-2020-13954 →CVE-2020-1925 →CVE-2020-10693 →CVE-2020-13956 →CVE-2020-28052 →CVE-2020-1938 →CVE-2020-5410 →CVE-2021-28165 →CVE-2020-1695 →CVE-2020-11996 →CVE-2020-17510 →CVE-2020-25633 →CVE-2020-25638 →CVE-2020-27216 →CVE-2017-5645 →CVE-2017-18640 →CVE-2019-12402 →CVE-2019-14887 →CVE-2020-6950 →CVE-2020-9484 →CVE-2020-13934 →CVE-2020-25640 →CVE-2019-16869 →CVE-2020-13920 →CVE-2020-14338 →CVE-2020-26258 →CVE-2020-26945 →CVE-2021-27807 →CVE-2020-5421 →CVE-2020-13935 →CVE-2020-14040 →CVE-2020-14297 →CVE-2020-14340 →CVE-2020-10688 →CVE-2020-10719 →CVE-2020-17518 →CVE-2020-25644 →

📋 Description

CVE-2017-5645 — log4j: Socket receiver deserialization vulnerability CVE-2017-18640 — snakeyaml: Billion laughs attack via alias feature CVE-2019-12402 — apache-commons-compress: Infinite loop in name encoding algorithm CVE-2019-14887 — wildfly: The 'enabled-protocols' value in legacy security is not respected if OpenSSL security provider is in use CVE-2019-16869 — netty: HTTP request smuggling by mishandled whitespace before the colon in HTTP headers CVE-2019-20445 — netty: HttpObjectDecoder.java allows Content-Length header to accompanied by second Content-Length header CVE-2020-1695 — resteasy: Improper validation of response header in MediaTypeHeaderDelegate.java class CVE-2020-1925 — olingo-odata: Server side request forgery in AsyncResponseWrapperImpl CVE-2020-1935 — tomcat: Mishandling of Transfer-Encoding header allows for HTTP request smuggling CVE-2020-1938 — tomcat: Apache Tomcat AJP File Read/Inclusion Vulnerability CVE-2020-5410 — spring-cloud-config-server: sending a request using a specially crafted URL can lead to a directory traversal attack CVE-2020-5421 — springframework: RFD protection bypass via jsessionid CVE-2020-6950 — Mojarra: Path traversal via either the loc parameter or the con parameter, incomplete fix of CVE-2018-14371 CVE-2020-9484 — tomcat: deserialization flaw in session persistence storage leading to RCE CVE-2020-10688 — RESTEasy: RESTEASY003870 exception in RESTEasy can lead to a reflected XSS attack CVE-2020-10693 — hibernate-validator: Improper input validation in the interpolation of constraint error messages CVE-2020-10714 — wildfly-elytron: session fixation when using FORM authentication CVE-2020-10719 — undertow: invalid HTTP request with large chunk size CVE-2020-11996 — tomcat: specially crafted sequence of HTTP/2 requests can lead to DoS CVE-2020-13920 — activemq: improper authentication allows MITM attack CVE-2020-13934 — tomcat: OutOfMemoryException caused by HTTP/2 connection leak could lead to DoS CVE-2020-13935 — tomcat: multiple requests with invalid payload length in a WebSocket frame could lead to DoS CVE-2020-13936 — velocity: arbitrary code execution when attacker is able to modify templates CVE-2020-13954 — cxf: XSS via the styleSheetPath CVE-2020-13956 — apache-httpclient: incorrect handling of malformed authority component in request URIs CVE-2020-14040 — golang.org/x/text: possibility to trigger an infinite loop in encoding/unicode could lead to crash CVE-2020-14297 — wildfly: Some EJB transaction objects may get accumulated causing Denial of Service CVE-2020-14338 — wildfly: XML validation manipulation due to incomplete application of use-grammar-pool-only in xercesImpl CVE-2020-14340 — xnio: file descriptor leak caused by growing amounts of NIO Selector file handles may lead to DoS CVE-2020-17510 — shiro: specially crafted HTTP request may cause an authentication bypass CVE-2020-17518 — apache-flink: directory traversal attack allows remote file writing through the REST API CVE-2020-25633 — resteasy-client: potential sensitive information leakage in JAX-RS RESTEasy Client's WebApplicationException handling CVE-2020-25638 — hibernate-core: SQL injection vulnerability when both hibernate.use_sql_comments and JPQL String literals are used CVE-2020-25640 — wildfly: resource adapter logs plaintext JMS password at warning level on connection error CVE-2020-25644 — wildfly-openssl: memory leak per HTTP session creation in WildFly OpenSSL CVE-2020-26258 — XStream: Server-Side Forgery Request vulnerability can be activated when unmarshalling CVE-2020-26945 — mybatis: mishandles deserialization of object streams which could result in remote code execution CVE-2020-27216 — jetty: local temporary directory hijacking vulnerability CVE-2020-28052 — bouncycastle: password bypass in OpenBSDBCrypt.checkPassword utility possible CVE-2021-27568 — json-smart: uncaught exception may lead to crash or information disclosure CVE-2021-27807 — pdfbox: infinite loop while loading a crafted PDF file CVE-2021-27906 — pdfbox: OutOfMemory-Exception while loading a crafted PDF file CVE-2021-28165 — jetty: Resource exhaustion when receiving an invalid large TLS frame

🎯 Affected products1

  • Red Hat Fuse 7.9

✅ 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.9.0 product documentation page: https://access.redhat.com/documentation/en-us/red_hat_fuse/7.9/ Workaround: Avoid using an OpenSSL security provider and instead use the default configuration or regular JSSE provider with 'TLS'. Workaround: * Use HTTP/2 instead (clear boundaries between requests) * Disable reuse of backend connections eg. ```http-reuse never``` in HAProxy or whatever equivalent LB settings Workaround: Workaround for Red Hat Satellite 6 is to add iptables rule to deny TCP requests of Tomcat that are not originating from the Satellite. For other Red Hat products, either mitigation isn't available or the currently available options don't meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability. Workaround: Please refer to the Red Hat knowledgebase article: https://access.redhat.com/solutions/4851251 Workaround: Users of vulnerable versions or older, unsupported versions of spring-cloud-config-server should upgrade to a patched version. Spring-cloud-config-server should only be accessible on internal networks. Workaround: There is no currently known mitigation for this flaw. Workaround: Users may configure the PersistenceManager with an appropriate value for sessionAttributeValueClassNameFilter to ensure that only application provided attributes are serialized and deserialized. For more details about the configuration, refer to the Apache Tomcat 9 Configuration Reference https://tomcat.apache.org/tomcat-9.0-doc/config/manager.html. Workaround: You can pass user input as an expression variable by unwrapping the context to HibernateConstraintValidatorContext. Please refer to the https://in.relation.to/2020/05/07/hibernate-validator-615-6020-released/ and https://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#_the_code_constraintvalidatorcontext_code. Workaround: This attack is dependent on the attacker being able to create a session and the victim accessing the session before the session expires, we do have a 15 minute session timeout by default but the attacker could also keep this alive by say sending in a request every five minutes. The server by default supports session tracking by URL and Cookie, if the web.xml is updated to support COOKIE only the exploit is not possible by sharing the link. ~~~ <session-config> <tracking-mode>URL</tracking-mode> </session-config> ~~~ TO ~~~ <session-config> <tracking-mode>COOKIE</tracking-mode> </session-config> ~~~ Workaround: Red Hat has investigated whether a possible mitigation exists for this issue, and has not been able to identify a practical example. Please update as soon as possible. Workaround: Users can disable the service listing altogether by setting the "hide-service-list-page" servlet parameter to "true". Workaround: Set hibernate.use_sql_comments to false, which is the default value, or use named parameters instead of literals. Please refer to details in https://docs.jboss.org/hibernate/orm/5.4/userguide/html_single/Hibernate_User_Guide.html#configurations-logging and https://docs.jboss.org/hibernate/orm/5.4/userguide/html_single/Hibernate_User_Guide.html#sql-query-parameters. Workaround: There is currently no known mitigation for this issue. 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: Jetty users should create temp folders outside the normal /tmp structure, and ensure that their permissions are set so as not to be accessible by an attacker. Workaround: Users unable to upgrade to version 1.67 or greater can copy the `OpenBSDBCrypt.doCheckPassword()` method implementation (https://github.com/bcgit/bc-java/blob/r1rv67/core/src/main/java/org/bouncycastle/crypto/generators/OpenBSDBCrypt.java#L259-L343) into their own utility class and supplement it with the required methods and variables as required

🔗 References (47)