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

We updated our summary at the top of this post (12/17/2021, 1:30am)
Best regards
Christoph Dyllick-Brenzinger

1 Like

I just updated my seafile pro server to 8.0.15 and followed the steps here to mitigate the log4j vulnerability:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

However, after running the (more recent) log4shell_1.4.1-log4shell_Linux_x86_64 tool to scan, I still get one security risk flagged regarding a different class (JndiManager):

root@files:~# ./log4shell_1.4.1-log4shell_Linux_x86_64 scan /srv/seafile/
8:23AM Scan Result: Identified vulnerable path
cve: CVE-2021-44228
fileName: org/apache/logging/log4j/core/net/JndiManager.class
hash: 293d7e83d4197f0496855f40a7745cfcdd10026dc057dfc1816de57295be88a6
path: /srv/seafile/seafile-pro-server-8.0.15/pro/elasticsearch/lib/log4j-core-2.11.1.jar
severity: 10.0
versionInfo: “2.10.0, 2.11.0, 2.11.1, 2.11.2, 2.9.0, 2.9.1”

Are there additional steps I need to take? Could you release an updated seafile-pro tarball with a version of log4j that is not vulnerable? I would really hate having to disable fulltext search, but right now, that seems the only safe thing to do?

1 Like

Yes, the best way is to disable full text search OR upgrade to 9.0.2. I’m not taking any risks, but that’s my choice. Dropping the class should suffice, but there’s too much speculation at the moment.

You can also remove the class and disable public libraries. This also reduces the chance of a successful attack.

Can 9.0.2 run with ES 7.x?

I think only 6.x, see:

and

1 Like

@Waschbuesch Thanks for this hint.

I tried the following and it seems to work:

You also need to run

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/net/JndiManager.class

inside /seafile-server-latest/pro/elasticsearch/lib/

After this, log4shell_1.4.1 won’t find any vulnerable path anymore and search still seems to work fine (tested with 8.0.14).

So in conclusion you would need to execute both commands in the directory /seafile-server-latest/pro/elasticsearch/lib/

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/net/JndiManager.class
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Upgraded to log4j 2.16? Surprise, there’s a 2.17 fixing DoS.

“If a string substitution is attempted for any reason on the following string, it will trigger an infinite recursion, and the application will crash,” state the JIRA issue, with a PoC payload:

${${::-${::-$${::-j}}}}

https://issues.apache.org/jira/browse/LOG4J2-3230

Although JNDI lookups were completely disabled in version 2.16, self-referential lookups remained a possibility under certain circumstances.

1 Like

btw: elastic 6.8 will be EOL on 8th of February :slight_smile:Elasticsearch | endoflife.date

So will there be a Seafile v9.1 supporting elastic 7? And when?

3 Likes

Version 9.0.2 pro doesn’t seem to be available in docker. Can you please make it available as soon as possible?

Do you have an estimate when it will be available?

In the meantime if someone else wants to fix the issue in their 8.0.14 install, here’s what I did:

docker-compose.yml:

  seafile:
#    image: docker.seadrive.org/seafileltd/seafile-pro-mc:8.0.14
    build:
        context: log4j_fix
        dockerfile: Dockerfile
    container_name: seafile
[...]

log4j_fix/Dockerfile:

# Custom Dockerfile
FROM docker.seadrive.org/seafileltd/seafile-pro-mc:8.0.14

# Install zip
RUN apt-get update -yqq \
    && apt-get install -y zip

# Patch log4j
WORKDIR /opt/seafile/seafile-pro-server-8.0.14/pro/elasticsearch/lib/
RUN zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

WORKDIR /opt/seafile/

You have a good point. We will use ElasticSearch 7 when Seafile pro v9.0 is officially released.

8 Likes

A new pro version 8.0.16 has been uploaded with the JndiLookup.class removed from log4j jar in bundled ElasticSearch.

5 Likes

Hi Daniel, will 8.0.16 make its way to docker hub sometime soon?
I’m curious to understand how docker builds are considered by Seafile org? They seem to lag behind more traditional methods, is this intentional or down to technical issues? Are they just not the preferred distribution mechanism?

thank you

# docker pull  docker.seadrive.org/seafileltd/seafile-pro-mc:8.0.16
Error response from daemon: manifest for docker.seadrive.org/seafileltd/seafile-pro-mc:8.0.16 not found: manifest unknown: manifest unknown

Hi EAf6WAor i think that # docker pull docker.seadrive.org/seafileltd/seafile-pro-mc:latest

will give you version 8.0.16. this is from my docker setup
/opt/seafile# ls -la
seafile-server-latest → seafile-pro-server-8.0.16

1 Like

What is needed to secure my docker-compose setup ?

i have updated to ver 8.0.16 and disabled elasticsearch in the docker-compose.yml file

#  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: 8g
#    volumes:
#      - /mnt/raid/Docker/seafile-elasticsearch/data:/usr/share/elasticsearch/data
#    networks:
#      - seafile_net
  seafile:
    image: docker.seadrive.org/seafileltd/seafile-pro-mc:latest

And i disabled this
/opt/seafile/conf# cat seafevents.conf

[INDEX FILES]
external_es_server = true
es_host = elasticsearch
es_port = 9200
enabled = false
interval = 10m

Do i need to do more? i am OK with search not working until version 9 is out.

Thanks

It was a mistake from one of our developer. We have a few docker repositories. He forgot to push to docker.seadrive.org.

As version 9.0, docker is the primary way to distribute Seafile. So docker images will be updated first.

1 Like