Critical Log4j security issue affects elasticsearch (0-day RCE!)

[wornet-aer]

Possible Mitigation: elastic/elasticsearch#81618

But we need to make sure, that the fix breaks no OTOBO functionalities.

[svenoe]

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

[xeraa]

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 :)

[svenoe]

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 RotherOSS/otobo#1505 - we will have to run some tests today before doing so, though.

Best regards, Sven