Closed wornet-aer closed 2 years ago
Hey Andreas,
thanks for the pr. We are having an eye on the situation, the elastic team has released a detailed statement which clearly claims, that neither the remote code execution nor the dns-lookup vulnerability apply to us, as OTOBO docker currently runs with JDK 16: https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476
In the github issue you cited there was an indirect claim, that Elasticsearch is vulnerable in general, but it was explained by @xeraa, that the example came from a system not only using Elasticsearch, after that. If you read that differently or have other information, please share it. Applying the hotfix is no real problem, but in the end we also had to release a new version of otobo, and I would rather do that based on more information, atm.
(Also the environment variables set in the elastic container should be harmless, even if they can be leaked.)
I don't really know what rotheross/otobo-elasticsearch:latest
is (https://github.com/RotherOSS/otobo-docker/blob/rel-10_0/.docker_compose_env_http#L54), but if you are on a recent 6.x or 7.x version you have avoided the worst. I'd still upgrade to the latest patch version of today to be on the safe side :)
Hi @xeraa - thanks for dropping by and yes, we intent to.
I will close this issue here, as this is set in otobo (an open source ticketing system and helpdesk, which optionally can use Elasticsearch) directly. I opened https://github.com/RotherOSS/otobo/issues/1505 - we will have to run some tests today before doing so, though.
Best regards, Sven
Possible Mitigation: https://github.com/elastic/elasticsearch/issues/81618
But we need to make sure, that the fix breaks no OTOBO functionalities.