We updated our summary at the top of this post (12/17/2021, 1:30am)
Best regards
Christoph Dyllick-Brenzinger
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?
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
@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.
btw: elastic 6.8 will be EOL on 8th of February
→ Elasticsearch | endoflife.date
So will there be a Seafile v9.1 supporting elastic 7? And when?
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.
A new pro version 8.0.16 has been uploaded with the JndiLookup.class removed from log4j jar in bundled ElasticSearch.
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
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.