5 ms·

"A project with a footprint like Log4j is not possible to avoid as a transient dependency even if you don’t directly import it. Log4j is a canonical logging uti

"A project with a footprint like Log4j is not possible to avoid as a transient dependency even if you don’t directly import it. Log4j is a canonical logging utility for a huge ecosystem. Its current radius is beyond doing due diligence." - @rakyll (AWS)

winternett 5y ago
I understand... The main point I'm addressing is whether an immediate A.O.R. will be in the line of "blowback", "compromise", and/or "fallout" with that statement. It's fun to stay at the C.Y.A. :P
mateuszf 5y ago
Yeah - for example to determine if log4j is used in a maven project one would have to run "mvn dependency:tree | grep log4j". Which I did today for our 60 microservices. And also for projects deployed as war files - container server libraries also have to be checked.
- blibble 5y ago
  you better hope one of your dependencies hasn't vendored it!
  - winternett 5y ago
    The key for me is to have a solid backup/disaster recovery plan in place and to first assess what rollback would entail and to verify that backup data is not corrupted. Rollback is more of a final (nuclear) option, but I always need to verify that it is an option... Data loss from rollback is far better than total corruption (if it ever gets to that point, God forbid). It also depends greatly on the availability needs for a system of course, but everyone has to be reasonable over things they can't pre-conceive or control in these types of situations because there's no way anything can operate flawlessly and without failure. 1. The Titanic 2. The Hindenburg 3. The AWS-East Service Outage This Month :\
- winternett 5y ago
  Also found this link today - https://support.lucidworks.com/hc/en-us/articles/4415649244055-Log4J-zero-day-vulnerability-CVE-2021-44228 https://support.lucidworks.com/hc/en-us/articles/44156492440... I'm glad I couldn't get SOLR to work on indexing PDFs for a client project last year and I chose an alternate solution after reading it today...
  - matwood 5y ago
    I mitigated our SOLR install over the weekend. Best I could tell it wasn't logging queries by default so I couldn't get it to trigger. Adding an extra JVM arg to the opt list is a pretty standard SOLR thing to do, so I already have automated ways to update and push out configuration changes.
- e12e 5y ago
  Ed: linked as "infoworld article" in TFA. This article[1] probably seems like a bit of convenient self-promotion from Anchore - but the two tools grype and syft https://github.com/anchore/grype https://github.com/anchore/grype https://github.com/anchore/syft https://github.com/anchore/syft Turned out to be very helpful in easily looking through folders, installed services (in particular an installed mobile device manager running on windows) and container images. [1] https://www.infoworld.com/article/3644492/how-to-detect-the-log4j-vulnerability-in-your-applications.html https://www.infoworld.com/article/3644492/how-to-detect-the-... Submitted to hn as: https://news.ycombinator.com/item?id=29543589 https://news.ycombinator.com/item?id=29543589 in case there's more discussion of tooling that might fit there.
- isbvhodnvemrwvn 5y ago
  It's probably worth refining it to `log4j-core`. `log4j-api` or various bridges like `log4j-to-slf4j` are not affected, but will show up in nearly any spring boot app.
  - kerblang 5y ago
    Just for reference here's the posting that confirms such: https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-s... Also worth noting this is not log4j 1, but log4j 2, like angular vs. angularjs. Version 2 is a backwards-incompatible rewrite with a different package structure, effectively a different product. Version 1 is unaffected by this mess.
- gunnarmorling 5y ago
  The Maven enforcer plug-in lets you fail the build if you'd depend on it either directly or indirectly [1]. Note this wouldn't find shaded usages. [1] https://twitter.com/gunnarmorling/status/1469603432269062146 https://twitter.com/gunnarmorling/status/1469603432269062146
- throwaway_JiY4E 5y ago
  Could it be you already are on Java 8u121? They say it: > protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
imwillofficial 5y ago
Can you parse this quote for me? I do not understand it.
- rareform 5y ago
  Even if you don't use l4j in your project, you are likely to use something that uses it; a transient dependency.
- fragmede 5y ago
  Even if your code doesn't directly use Log4j, it's exceedingly likely that a library you use, or a library that uses does.
- the_af 5y ago
  It means that even if your Java project doesn't directly use log4j as a dependency, nor mention it explicitly, it will be very likely included as a transitive dependency via other libs (and even logging frameworks!) that you use.
- winternett 5y ago
  They didn't get my original statement because I'm a PHP dev (no compiling involved)... sigh That being said, I do rely on containers, micro services, and other tools like Jenkins that will need eval.

winternett 5y ago

I understand... The main point I'm addressing is whether an immediate A.O.R. will be in the line of "blowback", "compromise", and/or "fallout" with that statement. It's fun to stay at the C.Y.A. :P

mateuszf 5y ago

Yeah - for example to determine if log4j is used in a maven project one would have to run "mvn dependency:tree | grep log4j". Which I did today for our 60 microservices. And also for projects deployed as war files - container server libraries also have to be checked.

blibble 5y ago
you better hope one of your dependencies hasn't vendored it!
- winternett 5y ago
  The key for me is to have a solid backup/disaster recovery plan in place and to first assess what rollback would entail and to verify that backup data is not corrupted. Rollback is more of a final (nuclear) option, but I always need to verify that it is an option... Data loss from rollback is far better than total corruption (if it ever gets to that point, God forbid). It also depends greatly on the availability needs for a system of course, but everyone has to be reasonable over things they can't pre-conceive or control in these types of situations because there's no way anything can operate flawlessly and without failure. 1. The Titanic 2. The Hindenburg 3. The AWS-East Service Outage This Month :\
winternett 5y ago
Also found this link today - https://support.lucidworks.com/hc/en-us/articles/4415649244055-Log4J-zero-day-vulnerability-CVE-2021-44228 https://support.lucidworks.com/hc/en-us/articles/44156492440... I'm glad I couldn't get SOLR to work on indexing PDFs for a client project last year and I chose an alternate solution after reading it today...
- matwood 5y ago
  I mitigated our SOLR install over the weekend. Best I could tell it wasn't logging queries by default so I couldn't get it to trigger. Adding an extra JVM arg to the opt list is a pretty standard SOLR thing to do, so I already have automated ways to update and push out configuration changes.
e12e 5y ago
Ed: linked as "infoworld article" in TFA. This article[1] probably seems like a bit of convenient self-promotion from Anchore - but the two tools grype and syft https://github.com/anchore/grype https://github.com/anchore/grype https://github.com/anchore/syft https://github.com/anchore/syft Turned out to be very helpful in easily looking through folders, installed services (in particular an installed mobile device manager running on windows) and container images. [1] https://www.infoworld.com/article/3644492/how-to-detect-the-log4j-vulnerability-in-your-applications.html https://www.infoworld.com/article/3644492/how-to-detect-the-... Submitted to hn as: https://news.ycombinator.com/item?id=29543589 https://news.ycombinator.com/item?id=29543589 in case there's more discussion of tooling that might fit there.
isbvhodnvemrwvn 5y ago
It's probably worth refining it to `log4j-core`. `log4j-api` or various bridges like `log4j-to-slf4j` are not affected, but will show up in nearly any spring boot app.
- kerblang 5y ago
  Just for reference here's the posting that confirms such: https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-s... Also worth noting this is not log4j 1, but log4j 2, like angular vs. angularjs. Version 2 is a backwards-incompatible rewrite with a different package structure, effectively a different product. Version 1 is unaffected by this mess.
gunnarmorling 5y ago
The Maven enforcer plug-in lets you fail the build if you'd depend on it either directly or indirectly [1]. Note this wouldn't find shaded usages. [1] https://twitter.com/gunnarmorling/status/1469603432269062146 https://twitter.com/gunnarmorling/status/1469603432269062146
throwaway_JiY4E 5y ago
Could it be you already are on Java 8u121? They say it: > protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".

imwillofficial 5y ago

Can you parse this quote for me? I do not understand it.

rareform 5y ago
Even if you don't use l4j in your project, you are likely to use something that uses it; a transient dependency.
fragmede 5y ago
Even if your code doesn't directly use Log4j, it's exceedingly likely that a library you use, or a library that uses does.
the_af 5y ago
It means that even if your Java project doesn't directly use log4j as a dependency, nor mention it explicitly, it will be very likely included as a transitive dependency via other libs (and even logging frameworks!) that you use.
winternett 5y ago
They didn't get my original statement because I'm a PHP dev (no compiling involved)... sigh That being said, I do rely on containers, micro services, and other tools like Jenkins that will need eval.