F5 SIRT on the Apache Commons Configuration CVE-2022-33980?
First, if all you need to know is whether any F5 products are impacted by this vulnerability, head on over to the Security Advisory here: https://support.f5.com/csp/article/K08006936
The Security Advisory is always the authoritative source of information when it comes to whether or not F5 products (or services) are impacted by vulnerabilities in both F5 owned code and third-party libraries and products F5 uses, such as Apache, OpenSSL and so on.
What is Commons Configuration?
Apache Commons Configuration is not, as you might think, related to the Apache webserver itself. It’s actually one of the many products from the Apache foundation and was released back in 2004 to act as a generic configuration interface between a Java application and arbitrary configuration data. Essentially a way to abstract the configuration layer from the application layer, allowing an application to read configuration information from sources like XML files, JDBC datasources, Windows INI files, JNDI and more, without the application needing to care so much about the syntax of each specific source.
Where did the problem creep in?
As we just discussed, Commons Configuration’s sole job is to read information from one source and present it in a controlled format to an application. Now, what is the hardest job in computing? Parsing input! Or, I should say, parsing input safely.
The specific problem we are talking about here happens when Commons Configuration handles input containing variables which are then substituted through a process of looking up the value in a remote source; that might be especially useful if you wish the configuration to be dynamically controlled depending on the execution environment, for example.
However, if an attacker is able to supply a maliciously crafted configuration file in some way, and therefore control what lookups are carried out, they might well be able to load malicious configuration into the application; for example, the ‘url’ variable causes Commons Configuration to read configuration from a remote destination, so if an attacker could supply “${url:UTF-8:https://www.example.com}” and the attacker controls ‘www.example.com’ , they can now push their own arbitrary configuration into the target application.
Of course, if you are using the ${url} directive and passing FQDNs that are registered publicly, you also need to make a point to maintain control over those FQDNs! Failure to do so could result in an attacker hijacking your application even if they can’t supply malicious configuration files directly.
So this is log4shell?
No, absolutely not.
The log4shell vulnerability targeted log4j, a Java based logging system which is designed specifically to ingest arbitrary, untrusted data. Unfortunately it performed similar variable substitution lookups allowing attackers to potentially hijack the underlying system.
This vulnerability, however, is in Commons Configuration which, in most cases, will not be operating on untrusted configuration files but rather configuration stored in your own application architecture or managed by trusted users. In short, there is no need to panic!
What if I am using untrusted configuration?
If you are accepting untrusted configuration into your application, then you should pay attention to what is being used in the variable substitution process. If the configuration is being passed in via a web application, then a web application firewall like Advanced WAF, F5 NGINX App Protect or Distributed Cloud Services could help by ensuring the input does not contain the Java notation above. F5 products have two signatures available at the time of writing, 200004450 and 200104775 (the former has existed since prior to 2019 and the latter since late 2021) which will both catch variants of the required exploit and you should check any Advanced WAF or NGINX App Protect policies have those signatures enabled if you are using Commons Configuration on untrusted input in this way.
[Updated 2022/07/13]
Three new signatures have also been added to Advanced WAF & NGINX App Protect; 200104807, 200104808 and 200104809. These are available once you have downloaded and applied the latest signature updates for your product (at least 20220712_133421 or later)
If your configuration comes in via another mechanism that may be attacker controlled then you will need to take care to implement protections within the application itself, or ensure that you have updated to a fixed version of Commons Configuration, of course.
And that’s it, in a nutshell:
- This isn’t log4shell, despite any outward similarities
- You probably don’t need to panic unless you’re using untrusted configuration in your applications
- If you are and it is passed in via the web, use a Web Application Firewall,
- Otherwise, build protection into the application or upgrade Commons Configuration
There are many deeper level dives into this CVE available today, so I’ll keep this article at this high level for now but feel free to comment with any questions if you have them!