SECURITY ADVISORY: Seafile Server's vulnerability to "Log4Shell" (log4j vulnerability, CVE-2021-44228)

Seafile Server
9

Hey everybody,

first I have to apologize for “FILE_INDEXING = false”. There is no such parameter in seafevents.conf. The full text search is configured in seafevents.conf with the following parameters:

[INDEX FILES]
enabled = true
index_office_pdf = true
…

(more infos here: seafevents.conf - Seafile Admin Manual)

But from my point of view the second parameter “index_office_pdf” is not relevant at all. If “enabled = true” then elasticsearch is started. If “enabled = false” there is no elasticsearch process and consequently no log4j no matter what value index_office_pdf has.

I just tested that behaviour some minutes ago:

  • enabled = false
  • in controller.log:
  • 2021-12-13 13:39:20 seafile-controller.c(462): search is not enabled

or …

  • enabled = true
  • in controller.log
  • 2021-12-13 13:52:17 seafile-controller.c(96): spawn_process: /home/seafile/seafile-pro-server-8.0.12/pro/elasticsearch/bin/elasticsearch -Epath.logs=/home/seafile/logs -Epath.data=/home/seafile/pro-data/search/data -Enetwork.host=127.0.0.1 -p /home/seafile/pids/elasticsearch.pid

I hope this helps.
Still the recommended solution to fix this issue (even by BSI: https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf?__blob=publicationFile&v=3) is by adding the parameter “-Dlog4j2.formatMsgNoLookups=true” to jvm.options.

Best regards
Christoph

10

@daniel.pan

Hi,
can you confirm it is also safe on the indexing process side?
poi/ExtractText.jar and poi/log4j-1.2.13.jar ?

Regards.

11

The vulnerability impacts Apache Log4j 2 versions 2.0 to 2.14.1. So log4j-1.2.13.jar is not affected. And ExtractText does not produce logs.

12

At the beginning there was a little doubt about log4j 1.x versions, but now we know that it is safe without the JMS Appender component.
And as you said that ExtractText does not produce logs, it is OK.
So thanks for your answer!

13

Short update from the Elasticsearch site:

Elasticsearch 5 is susceptible to both remote code execution and an information leak via DNS. For versions 5.6.11 - 5.6.16, this can be mitigated by setting the JVM option . Users on an earlier version of 5.x, are recommended to upgrade to 5.6.16.

As seafile seems to use Elasticsearch 5.6.13, the mitigation by setting the JVM option provides provides full protection against the RCE and information leak attacks according to the Elasticsearch page.

14

I’m using the docker version of Seafile Pro. Where is the config file for elasticsearch located in this setup?

(already asked here: URGENT! Zero-Day-Exploit in log4j - #20 by Unreality)

Regards,
Martin Angermeier

15

We updated our summary at the top of this post (dez. 14th, 6.15pm)
Best regards
Christoph Dyllick-Brenzinger

3 Likes
16

I don’t have a Docker-based Seafile Server at hand, so I cannot verify, but I’d assume that the docker-compose.yml gives a good hint:

elasticsearch:
image: seafileltd/elasticsearch-with-ik:5.6.16
container_name: seafile-elasticsearch
environment:
- discovery.type=single-node
- bootstrap.memory_lock=true
- “ES_JAVA_OPTS=-Xms1g -Xmx1g”
ulimits:
memlock:
soft: -1
hard: -1
mem_limit: 2g
volumes:
- /opt/seafile-elasticsearch/data:/usr/share/elasticsearch/data # Requested, specifies the path to Elasticsearch data persistent store.
networks:
- seafile-net

Have you checked the volume path?

17

Hi,

JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector.

In my case:(default ubuntu installation)

user@server:~# java -version
openjdk version “1.8.0_292”

Please note, this is LDAP only. There are also attacks using DNS and other protocols.

ldap[s]?|rmi|dns|nis|iiop|corba|nds|http

18

I think this is whats needed.

docker run \
...
    -e "ES_JAVA_OPTS=-Xms1g -Xmx1g -Dlog4j2.formatMsgNoLookups=true" 
...
19

Update from LunaSec:

The new CVE states:

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations.

We found this report concerning as it states that one of the recommended temporary mitigations for versions 2.7.0 <= Apache log4j <= 2.14.1 might not protect against this CVE. Further:

Note that previous mitigations involving configuration such as to set the system property log4j2.noFormatMsgLookup to true do NOT mitigate this specific vulnerability.

It was not readily apparently from reading this CVE what specifically was affected, or how this vulnerability is actually triggered. That’s why we actually tested this ourselves to figure out what the impact was.

Log4Shell Update: Second log4j Vulnerability Published (CVE-2021-44228 + CVE-2021-45046) | LunaTrace

@daniel.pan Is it possible to update ElasticSearch asap with log4j 2.16?

For other pro users: Disable ElasticSearch with

[INDEX FILES]
enabled = false

4 Likes
20

We have just uploaded Seafile Pro 9.0.2, which we have tested internally for a few weeks. You can use ElasticSearch 6.x version with Seafile Pro 9.0.2. ElasticSearch 6.x is still in support pediod.

1 Like
21

Do you think it would be possible to release such an update for Seafile Pro 8.x (and maybe older version lines that are still used and supported), too?

2 Likes
22

@daniel.pan

I agree, we would prefer a 8.x version with updated ElasticSearch as well.

And can you tell us which ElasticSearch 6 version is used ?

2 Likes
24

We can’t change included ElasticSearch packages in 8.0 version. If so, it is not much different from upgrading to version 9.0.

Compared to 8.0, 9.0 version mostly changes dependencies:

  • Upgrade to Django 3.2
  • Upgrading to ES 6.x
25

You can use any minor version of ElasticSearch 6.

26

But don’t you think using a separately installed elasticsearch would work in Seafile 8.0 basically the same way as in 9.0?

27

In version 8.0, you can use a separately installed elasticsearch. But the version has to be 5.6.x. So, it does not fix the problem.

28

Ah, I see. Okay.
And can you guess when Seafile 9.0 will officially lose the Beta status?

29

Thank you @daniel.pan !

Upgrade was successful and easy to do. Unfortunately I don’t have a docker, so I’m not using ElasticSearch in Seafile Pro 9.0.2.

I will disable [INDEX FILES] in version 9.0.2 for now.