5 ms·

Its just affecting the Apache Commons Text component. The title ("CVE-2022-42889: Java Apache Commons vulerability") is overly broad and suggests that somehow

by jabiko 4y ago

Its just affecting the Apache Commons Text component. 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

matsemann 4y ago
Agreed. I've seen/used Apache Commons on almost all big java projects I've ever touched in my career. But never the Text component. So the heading makes it seem like a big deal, while it probably is not? Unless it's used a lot implicitly. But even then I'm not sure how many actually uses the string interpolation functions.
- jillesvangurp 4y ago
  It's one of the oldest set of OSS libraries for Java that is still useful and actively maintained. Some of this stuff dates back to when it was still called Apache Jakarta in the nineties. Things like commons-io, commons-lang, etc. are very widely use in almost any Java code base. The only thing more common is the standard library. 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.
  - blincoln 4y ago
    Commons itself has been around for awhile, but it looks like Commons Text was first released in 2017: https://commons.apache.org/proper/commons-text/changes-report.html 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.
  - kitd 4y ago
    Unless you are actively using those functions, you should be fine. 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 is you friend!
- lolinder 4y ago
  Here is a list of packages that depend on commons-text [0]. Hadoop, Spark, and Apache Commons Configuration are some of the most popular projects to depend on commons-text. Not sure if they're using the vulnerable code paths, of course. [0] https://mvnrepository.com/artifact/org.apache.commons/commons-text/usages https://mvnrepository.com/artifact/org.apache.commons/common...
  - 19870213 4y ago
    Commons Configuration disabled the vulnerable parts by-default a couple of months ago.
gjvc 4y ago
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. 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.
- jabiko 4y ago
  > Nobody familiar with Java would interpret it this way 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.
- thesuperbigfrog 4y ago
  Apache Commons has 43 components: https://commons.apache.org/ https://commons.apache.org/ 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/commons-text/usages 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.

by jabiko 4y ago

matsemann 4y ago

Agreed. I've seen/used Apache Commons on almost all big java projects I've ever touched in my career. But never the Text component. So the heading makes it seem like a big deal, while it probably is not? Unless it's used a lot implicitly. But even then I'm not sure how many actually uses the string interpolation functions.

jillesvangurp 4y ago
It's one of the oldest set of OSS libraries for Java that is still useful and actively maintained. Some of this stuff dates back to when it was still called Apache Jakarta in the nineties. Things like commons-io, commons-lang, etc. are very widely use in almost any Java code base. The only thing more common is the standard library. 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.
- blincoln 4y ago
  Commons itself has been around for awhile, but it looks like Commons Text was first released in 2017: https://commons.apache.org/proper/commons-text/changes-report.html 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.
- kitd 4y ago
  Unless you are actively using those functions, you should be fine. 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 is you friend!
lolinder 4y ago
Here is a list of packages that depend on commons-text [0]. Hadoop, Spark, and Apache Commons Configuration are some of the most popular projects to depend on commons-text. Not sure if they're using the vulnerable code paths, of course. [0] https://mvnrepository.com/artifact/org.apache.commons/commons-text/usages https://mvnrepository.com/artifact/org.apache.commons/common...
- 19870213 4y ago
  Commons Configuration disabled the vulnerable parts by-default a couple of months ago.

gjvc 4y ago

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. 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.

jabiko 4y ago
> Nobody familiar with Java would interpret it this way 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.
thesuperbigfrog 4y ago
Apache Commons has 43 components: https://commons.apache.org/ https://commons.apache.org/ 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/commons-text/usages 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.