Java Apache Commons Text vulnerability
nvd.nist.gov
nvd.nist.gov
The title ("CVE-2022-42889: Java Apache Commons vulerability") is overly broad and suggests that somehow the whole Apache Commons project, which consists of over 40 components, has a vulnerability
To be clear, this is about a handful of utility functions in one of the libraries. Unless you are actively using those functions, you should be fine. And if you are, you'd be misguided to pass in unvalidated input straight from your APIs. That's almost always a bad idea with any library that implements functionality like this.
And of course it's something any security auditing would check on principle to see what falls over. I've been on multiple such projects where we found issues like this with other forms of string interpolation. It's a common junior mistake to not handle input properly and only do happy path testing.
If you are using these functions with e.g. configuration files or other strings under your control, it's not a problem; as that's pretty much the way this stuff is intended to be used. Disabling this is biasing on the border of better safe than sorry; which is a good thing of course. But if you need it, it's nice to not have to reinvent the wheel.
The other thing that's useful to know is that the maintainers of the Apache commons libraries have been pretty good about maintaining API compatibility. Some of these libraries have very infrequent updates but it still happens. Usually, updating these libraries is very low risk. I've never really seen good reasons to not update to minor releases of any apache commons libraries. You get bug fixes, some new functions, and generally no breakage whatsoever. And in the rare case something needs fixing, it's probably for a good reason.
https://commons.apache.org/proper/commons-text/changes-repor...
If I read the disclosure correctly, it's been vulnerable for four of the five years it's been publicly available.
Up to a point. As with all CVEs, the issue tend to be whether your dependencies are using it, or their dependencies, etc, etc.
mvn dependency:tree -Dverbose
[0] https://mvnrepository.com/artifact/org.apache.commons/common...
Nobody familiar with Java would interpret it this way. Also it's probably correct. There are vulnerabilities lurking in all software of any size and functionality, and Apache Commons is no exception.
When I read the title in the morning I had a short moment of panic because we make extensive use of for example Apache Commons Collections in our projects. Updating these libraries and delivering the fixes to customers would have resulted in quite some work.
If the title would have been more accurate it would probably have saved me from a mini heart-attack in the morning.
If the vulnerability is just in one component, it is important to be specific about which one it is.
Does anyone know what depends on Commons Text?
Edit: "Artifacts using Apache Commons Text" according to Maven:
https://mvnrepository.com/artifact/org.apache.commons/common...
There are some well-known projects that might be impacted: Hadoop, Spark, Velocity, Hive, Solr, and many more.
What's quite interesting is that the `env` Lookup is still enabled by default. If I understand correctly, this would imply that leaking environment variables is still possible even with the fix, if the attacker has an injection point and access to the return value of the vulnerable function.
[1] https://commons.apache.org/proper/commons-text/apidocs/org/a...
So, if you let untrusted users somehow set configuration, then you're vulnerable.
Never a bad idea to remove an attack surface, but damn, you'd have to plan 3 - 4 sprints ahead to mess up bad enough to let third parties set config files. (And besides, as log4j2 showed us, if you want to allow that, LDAP is how the cool kids do it.)
According to the sentence before the of about untrusted configurations, "untrusted" configuration includes the default: unless your configuration is explicitly hardened, any call to the string interpolator with unsanitized content is an open door. (the open question is wether calls to the string interpolator exist)
Given as it was the maintainers who lodged the CVE, and their description that I was quoting, I'm reasonably happy it's a correct statement.
I'll be honest, I haven't dived into the code to verify that myself.
But if you have, please feel free to share your findings :)
Having a replacement that is based on arbitrary scripts (!) seems especially questionable to me, in my brain that is a niche use case and should be turned off by default.
Maybe we have to sharpen the awareness of the common developer to these kind of dangerous practices, like we did with SQL injection attacks where string concatenation to create your queries is generally frowned upon and is regarded as a bad practice industry-wide.
I'm coming from the Explicit Is Better Than Implicit world, where things like Jinja2 keep templates doing templatey things, so perhaps I'm biased, but it seems incredible that anyone thought that allowing functionality like this to be accessible directly from string templating was a good idea.
With so many eval() in the wild and viruses injecting random strings, I’m actually surprised so system became randomly sentient.
The fix is just to turn it off by default. If you need it, presumably you will have to ensure that untrusted or unsanitised user input can't reach it.
Vulnerabilities are not bugs. They are vulnerabilities. They often arise from bugs, but not always.
I had expected that all code like that would have been scrutinized immediately.
Yes, it appears similar. It involves string interpolation that leads to arbitrary code execution via crafted values. It's also similar in that Apache Commons components are widespread and deeply embedded in innumerable backend systems.
I wonder how widespread this particular Commons component is in real world. I can't recall ever explicitly seeking it out as a direct dependency myself. However, it is probably a common transitory dependency. It shows up as being used by a few thousand other Java components on mvnrepository.com, although at first glance I didn't see things in the list of usages that made me panic.
The ones that stick out are Commons JPA, Apache ServiceMix and Apache Turbine and Struts 2.
Disclaimer: The above is not comprehensive. Just me clicking around a few minutes. Don't bet your career on it.
Here, the interpolation happens on a string that is expected to be a template (it's even documented that way), so users would usually be cautious where the template originates from. Recursive interpolation also needs to be enabled explicitly.
(in title)