By the Year
In 2022 there have been 2 vulnerabilities in Apache Karaf with an average score of 6.7 out of ten. Last year Karaf had 1 security vulnerability published. That is, 1 more vulnerability have already been reported in 2022 as compared to last year. However, the average CVE base score of the vulnerabilities in 2022 is greater by 1.20.
It may take a day or so for new Karaf vulnerabilities to show up in the stats or in the list of recent security vulnerabilties. Additionally vulnerabilities may be tagged under a different product or component name.
Recent Apache Karaf Security Vulnerabilities
Apache Karaf obr:* commands and run goal on the karaf-maven-plugin have partial path traversal which allows to break out of expected folder
5.3 - Medium
- January 26, 2022
Apache Karaf obr:* commands and run goal on the karaf-maven-plugin have partial path traversal which allows to break out of expected folder. The risk is low as obr:* commands are not very used and the entry is set by user. This has been fixed in revision: https://gitbox.apache.org/repos/asf?p=karaf.git;h=36a2bc4 https://gitbox.apache.org/repos/asf?p=karaf.git;h=52b70cf Mitigation: Apache Karaf users should upgrade to 4.2.15 or 4.3.6 or later as soon as possible, or use correct path. JIRA Tickets: https://issues.apache.org/jira/browse/KARAF-7326
Apache Karaf allows monitoring of applications and the Java runtime by using the Java Management Extensions (JMX)
8.1 - High
- January 26, 2022
Apache Karaf allows monitoring of applications and the Java runtime by using the Java Management Extensions (JMX). JMX is a Java RMI based technology that relies on Java serialized objects for client server communication. Whereas the default JMX implementation is hardened against unauthenticated deserialization attacks, the implementation used by Apache Karaf is not protected against this kind of attack. The impact of Java deserialization vulnerabilities strongly depends on the classes that are available within the targets class path. Generally speaking, deserialization of untrusted data does always represent a high security risk and should be prevented. The risk is low as, by default, Karaf uses a limited set of classes in the JMX server class path. It depends of system scoped classes (e.g. jar in the lib folder).
Netty is an open-source
5.5 - Medium
- February 08, 2021
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty before version 4.1.59.Final there is a vulnerability on Unix-like systems involving an insecure temp file. When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems. The method "File.createTempFile" on unix-like systems creates a random file, but, by default will create this file with the permissions "-rw-r--r--". Thus, if sensitive information is written to this file, other local users can read this information. This is the case in netty's "AbstractDiskHttpData" is vulnerable. This has been fixed in version 4.1.59.Final. As a workaround, one may specify your own "java.io.tmpdir" when you start the JVM or use "DefaultHttpDataFactory.setBaseDir(...)" to set the directory to something that is only readable by the current user.
Creation of Temporary File With Insecure Permissions
An issue was discovered in Legion of the Bouncy Castle BC Java 1.65 and 1.66
8.1 - High
- December 18, 2020
An issue was discovered in Legion of the Bouncy Castle BC Java 1.65 and 1.66. The OpenBSDBCrypt.checkPassword utility method compared incorrect data when checking the password, allowing incorrect passwords to indicate they were matching with previously hashed ones that were different.
In Karaf, JMX authentication takes place using JAAS and authorization takes place using ACL files
6.3 - Medium
- June 12, 2020
In Karaf, JMX authentication takes place using JAAS and authorization takes place using ACL files. By default, only an "admin" can actually invoke on an MBean. However there is a vulnerability there for someone who is not an admin, but has a "viewer" role. In the 'etc/jmx.acl.cfg', such as role can call get*. It's possible to authenticate as a viewer role + invokes on the MLet getMBeansFromURL method, which goes off to a remote server to fetch the desired MBean, which is then registered in Karaf. At this point the attack fails as "viewer" doesn't have the permission to invoke on the MBean. Still, it could act as a SSRF style attack and also it essentially allows a "viewer" role to pollute the MBean registry, which is a kind of privilege escalation. The vulnerability is low as it's possible to add a ACL to limit access. Users should update to Apache Karaf 4.2.9 or newer.
Apache Karaf Config service provides a install method (via service or MBean)
4.9 - Medium
- May 09, 2019
Apache Karaf Config service provides a install method (via service or MBean) that could be used to travel in any directory and overwrite existing file. The vulnerability is low if the Karaf process user has limited permission on the filesystem. Any Apache Karaf version before 4.2.5 is impacted. User should upgrade to Apache Karaf 4.2.5 or later.
Apache Karaf kar deployer reads .kar archives and extracts the paths from the "repository/" and "resources/" entries in the zip file
6.5 - Medium
- March 21, 2019
Apache Karaf kar deployer reads .kar archives and extracts the paths from the "repository/" and "resources/" entries in the zip file. It then writes out the content of these paths to the Karaf repo and resources directories. However, it doesn't do any validation on the paths in the zip file. This means that a malicious user could craft a .kar file with ".." directory names and break out of the directories to write arbitrary content to the filesystem. This is the "Zip-slip" vulnerability - https://snyk.io/research/zip-slip-vulnerability. This vulnerability is low if the Karaf process user has limited permission on the filesystem. Any Apache Karaf releases prior 4.2.3 is impacted.
Apache Karaf provides a features deployer, which
9.8 - Critical
- January 07, 2019
Apache Karaf provides a features deployer, which allows users to "hot deploy" a features XML by dropping the file directly in the deploy folder. The features XML is parsed by XMLInputFactory class. Apache Karaf XMLInputFactory class doesn't contain any mitigation codes against XXE. This is a potential security risk as an user can inject external XML entities in Apache Karaf version prior to 4.1.7 or 4.2.2. It has been fixed in Apache Karaf 4.1.7 and 4.2.2 releases.
In Apache Karaf prior to 4.2.0 release, if the sshd service in Karaf is left on so an administrator can manage the running instance, any user with rights to the Karaf console can pivot and read/write any file on the file system to
8.8 - High
- September 18, 2018
In Apache Karaf prior to 4.2.0 release, if the sshd service in Karaf is left on so an administrator can manage the running instance, any user with rights to the Karaf console can pivot and read/write any file on the file system to which the Karaf process user has access. This can be locked down a bit by using chroot to change the root directory to protect files outside of the Karaf install directory; it can be further locked down by defining a security manager policy that limits file system access to those directories beneath the Karaf home that are necessary for the system to run. However, this still allows anyone with ssh access to the Karaf process to read and write a large number of files as the Karaf process user.
Improper Privilege Management
In Apache Karaf version prior to 3.0.9, 4.0.9, 4.1.1, when the webconsole feature is installed in Karaf, it is available at
8.1 - High
- September 18, 2018
In Apache Karaf version prior to 3.0.9, 4.0.9, 4.1.1, when the webconsole feature is installed in Karaf, it is available at .../system/console and requires authentication to access it. One part of the console is a Gogo shell/console that gives access to the command line console of Karaf via a Web browser, and when navigated to it is available at .../system/console/gogo. Trying to go directly to that URL does require authentication. And optional bundle that some applications use is the Pax Web Extender Whiteboard, it is part of the pax-war feature and perhaps others. When it is installed, the Gogo console becomes available at another URL .../gogo/, and that URL is not secured giving access to the Karaf console to unauthenticated users. A mitigation for the issue is to manually stop/uninstall Gogo plugin bundle that is installed with the webconsole feature, although of course this removes the console from the .../system/console application, not only from the unauthenticated endpoint. One could also stop/uninstall the Pax Web Extender Whiteboard, but other components/applications may require it and so their functionality would be reduced/compromised.