Which I did today for our 60 microservices.
And also for projects deployed as war files - container server libraries also have to be checked.
Which I did today for our 60 microservices.
And also for projects deployed as war files - container server libraries also have to be checked.
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.
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/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-...
Submitted to hn as: https://news.ycombinator.com/item?id=29543589 in case there's more discussion of tooling that might fit there.
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...
[1] https://twitter.com/gunnarmorling/status/1469603432269062146
> protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
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
:\