RHSA-2021:3205MediumCVSS 9.0

Red Hat Security Advisory: Red Hat Integration Camel-K 1.4 release and security update

Published
August 18, 2021
Last Modified
August 4, 2026

🔗 CVE IDs covered (18)

CVE-2020-27222 →CVE-2021-30468 →CVE-2021-31811 →CVE-2020-13954 →CVE-2020-17518 →CVE-2020-27782 →CVE-2020-28052 →CVE-2021-20218 →CVE-2021-27807 →CVE-2021-27906 →CVE-2020-13920 →CVE-2020-26238 →CVE-2020-26259 →CVE-2020-29582 →CVE-2021-22118 →CVE-2020-17521 →CVE-2020-26217 →CVE-2020-26258 →

📋 Description

CVE-2020-13920 — activemq: improper authentication allows MITM attack CVE-2020-13954 — cxf: XSS via the styleSheetPath CVE-2020-17518 — apache-flink: directory traversal attack allows remote file writing through the REST API CVE-2020-17521 — groovy: OS temporary directory leads to information disclosure CVE-2020-26217 — XStream: remote code execution due to insecure XML deserialization when relying on blocklists CVE-2020-26238 — cron-utils: template injection allows attackers to inject arbitrary Java EL expressions leading to remote code execution CVE-2020-26258 — XStream: Server-Side Forgery Request vulnerability can be activated when unmarshalling CVE-2020-26259 — XStream: arbitrary file deletion on the local host when unmarshalling CVE-2020-27222 — californium-core: DTLS - DoS vulnerability for certificate based handshakes CVE-2020-27782 — undertow: special character in query results in server errors CVE-2020-28052 — bouncycastle: password bypass in OpenBSDBCrypt.checkPassword utility possible CVE-2020-29582 — kotlin: vulnerable Java API was used for temporary file and folder creation which could result in information disclosure CVE-2021-20218 — fabric8-kubernetes-client: vulnerable to a path traversal leading to integrity and availability compromise CVE-2021-22118 — spring-web: (re)creating the temporary storage directory could result in a privilege escalation within WebFlux application 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-30468 — CXF: Denial of service vulnerability in parsing JSON via JsonMapObjectReaderWriter CVE-2021-31811 — pdfbox: OutOfMemory-Exception while loading a crafted PDF file

🎯 Affected products1

  • Red Hat Integration

✅ Remediation

Before applying this update, make sure all previously released errata relevant to your system have been applied. For details on how to apply this update, refer to: https://access.redhat.com/articles/11258 Workaround: Users can disable the service listing altogether by setting the "hide-service-list-page" servlet parameter to "true". 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: 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 (18)