Hello all,
Here's an important security message from the Wikibase development team.
We are aware of the vulnerability in log4j announced on December 9, 2021: CVE-2021-44228 [1] aka log4shell [2]. In our Wikibase Docker install, the only piece of software affected by this vulnerability is the version of Elasticsearch we currently use, 6.5.4. This is an older version of Elasticsearch. For now, users of the wikibase-release-pipeline Docker images should circumvent this vulnerability by disabling log4j lookups.
To circumvent the vulnerability, you can add the following Java option to the ES_JAVA_OPTS variable specified in your docker-compose(-extra).yml file and restart your Docker images:
-Dlog4j2.formatMsgNoLookups=true
This patch is also available on our github mirror [3].
Going forward we will carefully vet any new software or new versions of existing software to ensure the log4shell vulnerability is not present.
Feel free to respond here or on our questions page [4] with any questions or concerns. Thanks for your attention. This announcement is also available as a web page here [5].
Best regards, Léa Lacroix
[1] https://www.cve.org/CVERecord?id=CVE-2021-44228
[2] https://en.wikipedia.org/wiki/Log4Shell
[3] https://github.com/wmde/wikibase-release-pipeline/commit/6b1342e94b1d75df103...
[4] https://www.mediawiki.org/wiki/Talk:Wikibase/FAQ?dtenable=1
[5] https://www.mediawiki.org/wiki/Wikibase/Announcements/2021-12-14
Thank you Lea! Is there a recommended way for testing if the configuration is effective and the lookup is indeed disabled? Yours, Dragan
On Tue, Dec 14, 2021 at 3:00 PM Léa Lacroix lea.lacroix@wikimedia.de wrote:
Hello all,
Here's an important security message from the Wikibase development team.
We are aware of the vulnerability in log4j announced on December 9, 2021: CVE-2021-44228 [1] aka log4shell [2]. In our Wikibase Docker install, the only piece of software affected by this vulnerability is the version of Elasticsearch we currently use, 6.5.4. This is an older version of Elasticsearch. For now, users of the wikibase-release-pipeline Docker images should circumvent this vulnerability by disabling log4j lookups.
To circumvent the vulnerability, you can add the following Java option to the ES_JAVA_OPTS variable specified in your docker-compose(-extra).yml file and restart your Docker images:
-Dlog4j2.formatMsgNoLookups=true
This patch is also available on our github mirror [3].
Going forward we will carefully vet any new software or new versions of existing software to ensure the log4shell vulnerability is not present.
Feel free to respond here or on our questions page [4] with any questions or concerns. Thanks for your attention. This announcement is also available as a web page here [5].
Best regards, Léa Lacroix
[1] https://www.cve.org/CVERecord?id=CVE-2021-44228
[2] https://en.wikipedia.org/wiki/Log4Shell
[3] https://github.com/wmde/wikibase-release-pipeline/commit/6b1342e94b1d75df103...
[4] https://www.mediawiki.org/wiki/Talk:Wikibase/FAQ?dtenable=1
[5] https://www.mediawiki.org/wiki/Wikibase/Announcements/2021-12-14
-- Léa Lacroix Community Engagement Coordinator
Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207. _______________________________________________ Wikibaseug mailing list -- wikibaseug@lists.wikimedia.org To unsubscribe send an email to wikibaseug-leave@lists.wikimedia.org
Hi Dragan, Thanks a lot for your question. We are working on a reliable way to test this to our satisfaction. Initial examination suggests that https://log4shell.huntress.com/ may be a good way to perform such a test, though it's provided by a third party which we can't ourselves vouch for. You can also have a look at the recent statement from ElasticSearch: https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnera... I hope this helps a little bit!
On Tue, 14 Dec 2021 at 16:46, Dragan Espenschied < dragan.espenschied@rhizome.org> wrote:
Thank you Lea! Is there a recommended way for testing if the configuration is effective and the lookup is indeed disabled? Yours, Dragan
On Tue, Dec 14, 2021 at 3:00 PM Léa Lacroix lea.lacroix@wikimedia.de wrote:
Hello all,
Here's an important security message from the Wikibase development team.
We are aware of the vulnerability in log4j announced on December 9, 2021: CVE-2021-44228 [1] aka log4shell [2]. In our Wikibase Docker install, the only piece of software affected by this vulnerability is the version of Elasticsearch we currently use, 6.5.4. This is an older version of Elasticsearch. For now, users of the wikibase-release-pipeline Docker images should circumvent this vulnerability by disabling log4j lookups.
To circumvent the vulnerability, you can add the following Java option to the ES_JAVA_OPTS variable specified in your docker-compose(-extra).yml file and restart your Docker images:
-Dlog4j2.formatMsgNoLookups=true
This patch is also available on our github mirror [3].
Going forward we will carefully vet any new software or new versions of existing software to ensure the log4shell vulnerability is not present.
Feel free to respond here or on our questions page [4] with any questions or concerns. Thanks for your attention. This announcement is also available as a web page here [5].
Best regards, Léa Lacroix
[1] https://www.cve.org/CVERecord?id=CVE-2021-44228
[2] https://en.wikipedia.org/wiki/Log4Shell
[3] https://github.com/wmde/wikibase-release-pipeline/commit/6b1342e94b1d75df103...
[4] https://www.mediawiki.org/wiki/Talk:Wikibase/FAQ?dtenable=1
[5] https://www.mediawiki.org/wiki/Wikibase/Announcements/2021-12-14
-- Léa Lacroix Community Engagement Coordinator
Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207. _______________________________________________ Wikibaseug mailing list -- wikibaseug@lists.wikimedia.org To unsubscribe send an email to wikibaseug-leave@lists.wikimedia.org
--
Dragan Espenschied Preservation Director Rhizome http://rhizome.org at the New Museum
Wikibaseug mailing list -- wikibaseug@lists.wikimedia.org To unsubscribe send an email to wikibaseug-leave@lists.wikimedia.org
Is there a recommended way for testing if the configuration is effective and the lookup is indeed disabled?
The log file for the container contains an entry for JVM arguments on startup, which should include Dlog4j2.formatMsgNoLookups=true if fixed. This can be accessed by 'docker logs xxx' on the ElasticSearch container.
It'd be nice to have a test case, though - I tried pasting a test string from the web-based tool mentioned into the MediaWiki search box, but I am not sure if this is a suitable test.
FWIW, Docker doesn't make it easy to modify an existing container's environment for quick fixes without making a whole new one. Of course the "right" way is to recompose it. However, if for any reason you don't have files to hand, and don't want to mess around with an overlay like https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay (which I'm not sure works; it depends on the version of log4j used), or don't want to switch containers, it seems possible to modify the environment for existing ones directly.
I found the container ID for elasticsearch with 'docker ps', stopped the docker daemon with 'systemctl stop docker' (stopping the specific container is not enough), edited config.v2.json in /var/lib/docker/containers/xxx... such that the ES_JAVA_OPTS had the additional option and then 'systemctl start docker' - judging by tail -n 50 of the log file in that directory, the environment variable was correctly set. Take that with a huge pinch of salt, though; I'm not a docker expert. 😅
-- Laurence 'GreenReaper' Parry
wikibaseug@lists.wikimedia.org