search

jhu-idc / iDC-general

Contains non-code-base specific tickets relating to the Islandora8 for Digital Collection project
0 stars 0 forks source link

Update ISLE containers to fix Java security issue #458

Closed bseeger closed 2 years ago

bseeger commented 2 years ago

We should look into this issue and see what we can do to resolve it:

https://www.lunasec.io/docs/blog/log4j-zero-day/

Folks in the Islandora ISLE community are looking at this as well, so it might be good to check in with them so see what solutions ISLE itself comes up with.

bseeger commented 2 years ago

We use solr: 8.9.0. We should move that up to 8.11.1 or greater to get past this issue: Solr writeup

bseeger commented 2 years ago

Cantaloupe is safe: https://github.com/cantaloupe-project/cantaloupe/issues/540

bseeger commented 2 years ago

Blaze graph and FITS could be issues, but we don't (or will not) run both of them in production (there's a PR in idc-isle-dc to shut off running the FITS container and triggering FITS derivs).

Alpaca/Active MQ need to be checked.

bseeger commented 2 years ago

ISLE Is thinking of adding some tooling to check for vulnerabilities. https://github.com/Islandora-Devops/isle-buildkit/issues/168

bseeger commented 2 years ago

@little9 noted that for kubernetes, one could do this: 

Kubernetes administrators may use “kubectl set env” to set the LOG4J_FORMAT_MSG_NO_LOOKUPS=“true” 
environment variable to apply the mitigation across Kubernetes clusters where the Java applications are running Log4j 
2.10 to 2.14.1, effectively reflecting on all pods and containers automatically.

Maybe that would be the best temporary solution for IDC? 
https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/

@jhujasonw noted that that only works if the log4j version is at least 2.10

I'm noting that solr is using: 2.13.2 for log4j (and 1.7.24 for slf4j in case that's useful)

bseeger commented 2 years ago

should be fixed with the update to solr 8.11.1