Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2021-44228 vulnerability Log4j (Solr)? #4375

Closed
4 tasks done
gaetandezeiraud opened this issue Dec 11, 2021 · 27 comments
Closed
4 tasks done

CVE-2021-44228 vulnerability Log4j (Solr)? #4375

gaetandezeiraud opened this issue Dec 11, 2021 · 27 comments
Labels

Comments

@gaetandezeiraud
Copy link

gaetandezeiraud commented Dec 11, 2021

Prior to placing the issue, please check following: (fill out each checkbox with an X once done)

  • I understand that not following or deleting the below instructions will result in immediate closure and/or deletion of my issue.
  • I have understood that this bug report is dedicated for bugs, and not for support-related inquiries.
  • I have understood that answers are voluntary and community-driven, and not commercial support.
  • I have verified that my issue has not been already answered in the past. I also checked previous issues.

Summary

Mailcow is vulnerable to CVE-2021-44228 Log4j?
https://community.mailcow.email/d/1229-cve-2021-44228-vulnerability-solr

@andryyy
Copy link
Contributor

andryyy commented Dec 11, 2021 via email

@gaetandezeiraud
Copy link
Author

Don't know. It is more a question about if mailcow is potentially vulnerable or not.
By security, I have shutdown my mail servers until I get an answer.

@andryyy
Copy link
Contributor

andryyy commented Dec 11, 2021 via email

@andryyy
Copy link
Contributor

andryyy commented Dec 11, 2021

theoretically trivial

How?

@MAGICCC
Copy link
Member

MAGICCC commented Dec 11, 2021

Seems Solr doesnt even have an update ready on their site: https://solr.apache.org/downloads.html
And they claim that 8.11.1 is safe: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228

Either way: We need to update to 8.x sooner or later since this is their stable release for now.

@gaetandezeiraud
Copy link
Author

apache/solr#454

@gaetandezeiraud
Copy link
Author

theoretically trivial

How?

It is enough that a bad string is sent somewhere and which arrives to solr which logs it and it is finished. Code execution.

@jonprocter
Copy link

jonprocter commented Dec 11, 2021

I've just disabled Solr on my mailcow servers to mitigate any potential risk from this, and everything seems to be working to the point I don't even know if to bother turning it back on when it's fixed (for reference for anybody reading who isn't sure: set SKIP_SOLR=y in mailcow.conf, line 143 for me, and then run docker-compose up -d)

@marc1006
Copy link

An easy workaround would be to use the "fix/workaround" suggested in apache/solr#454 (comment)
(adding SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true").

@gaetandezeiraud
Copy link
Author

@marc1006 Can you write an explanation of how to do this? Step by step.

@marc1006
Copy link

marc1006 commented Dec 11, 2021

At best, this should be fixed in the solr image used by Mailcow by the maintainer of Mailcow. Probably by either adapting this file https://github.com/mailcow/mailcow-dockerized/blob/master/data/Dockerfiles/solr/solr.sh or the Dockerfile https://github.com/mailcow/mailcow-dockerized/blob/master/data/Dockerfiles/solr/Dockerfile

Note: I'm not familiar with the Mailcow code base.

@Brouilles
Please perform the steps below only if you know what you're doing (and have a backup)

  1. Edit the file data/Dockerfiles/solr/solr.sh (https://github.com/mailcow/mailcow-dockerized/blob/master/data/Dockerfiles/solr/solr.sh)
    e.g.
...
if [[ "${1}" == "--bootstrap" ]]; then
  echo "Creating initial configuration"
  ### ADD THE LINE BELOW
  echo 'SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"' >> /opt/solr/bin/solr.in.sh
  ###
  echo "Modifying default config set"
  ...
  1. Build the docker image (and tag it as mailcow/solr:tmpfix)
    e.g.
    # docker build data/Dockerfiles/solr -t mailcow/solr:tmpfix
  2. Adapt docker-compose.yml so our newly created docker image is used
...
    solr-mailcow:
      image: mailcow/solr:tmpfix
...
  1. Restart Mailcow
    # docker-compose up -d

Once there is a fix in Mailcow, you will need to revert/undo the changes I suggested (and delete the mailcow/solr:tmpfix docker image) before updating Mailcow!!!!

@gaetandezeiraud
Copy link
Author

Thanks @jonprocter I have do the same.

@yoyellow
Copy link

yoyellow commented Dec 12, 2021

e1db347

is pushed. am i correct in assuming that this resolves the vulnerability CVE-2021-44228 @andryyy

@andryyy
Copy link
Contributor

andryyy commented Dec 12, 2021

The Solr vulnerability was fixed, yes.

mailcow was never directly affected.

@gaetandezeiraud
Copy link
Author

The Solr vulnerability was fixed, yes.

mailcow was never directly affected.

I am not so sure. https://twitter.com/gossithedog/status/1469993248559140864?s=21

@andryyy
Copy link
Contributor

andryyy commented Dec 12, 2021 via email

@jonprocter
Copy link

The Solr vulnerability was fixed, yes.

mailcow was never directly affected.

that's great, thanks!

@fluxens
Copy link

fluxens commented Dec 12, 2021

Checking solr.log in the solr container reveals that every search via the UI is logged verbatim:

webapp=/solr path=/select params={q={!lucene+q.op%3DAND}subject:exploit_goes_here+OR+from:exploit_goes_here&fl=uid,score&sort=uid+asc&fq=%2Bbox:35007c1e32358461310200006dabb843+%2Buser:test@test.de&rows=14&wt=xml} hits=0 status=0 QTime=4

solr uses log4j, so I would not say that it is not affected at all.

@PH89
Copy link

PH89 commented Dec 12, 2021

@andryyy Could you gave some details how is was fixed ? Because your Solr docker images still uses version 7.7.3.
Just updating the image from 1.7 to 1.8 is not providing enough information.

@fluxens
Copy link

fluxens commented Dec 12, 2021

I was curious myself, so I compared 1.7 and 1.8:

/opt/docker-solr/scripts/start-local-solr

-MY_SOLR_OPTS="${MY_SOLR_OPTS:-} -Djetty.host=${SOLR_LOCAL_HOST:-localhost}"
+MY_SOLR_OPTS="${MY_SOLR_OPTS:-} -Djetty.host=${SOLR_LOCAL_HOST:-localhost} -Dlog4j2.formatMsgNoLookups=true"

/opt/docker-solr/scripts/solr-fg

+EXTRA_ARGS+=('-Dlog4j2.formatMsgNoLookups=true')

@MAGICCC
Copy link
Member

MAGICCC commented Dec 12, 2021

It uses this patch now: docker-solr/docker-solr@74d04b4
image

@digitalkram
Copy link

digitalkram commented Dec 12, 2021

1.8 uses jvm property "-Dlog4j2.formatMsgNoLookups=true" so it should be safe

EDIT: blargh. I was too slow 😉 Sorry for basically repeating the contentof the two previous posts 😓

@PH89
Copy link

PH89 commented Dec 12, 2021

Okay I can confirm that setting is set. 👍🏻

@MAGICCC MAGICCC closed this as completed Dec 13, 2021
@tacerus
Copy link

tacerus commented Dec 14, 2021

Ah yes, the classic "it's not an issue til it becomes an issue".

@k00b0ld
Copy link

k00b0ld commented Dec 15, 2021

Latest insight: to set the system property Dlog4j2.formatMsgNoLookups to true do NOT mitigate this specific vulnerability

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046

@MAGICCC
Copy link
Member

MAGICCC commented Dec 15, 2021

Yep indeed, but solr is still not affected:

Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set
The MDC Patterns used by solr are for the collection, shard, replica, core
and node names, and a potential trace id. All of those are restricted to
alphanumeric, no special characters like $ or { needed for the injection.
And trying to access a collection that didn’t exist Returns 404 without
logging.
Upgrading is always going to be more complete, but I think we’re still ok
for now, at least until the next iteration of this attack surfaces.

docker-solr/docker-solr#397 (comment)

@sebiboga
Copy link

well... you can use:

[Windows] set "START_OPTS=%START_OPTS% -Dlog4j2.formatMsgNoLookups=true"
(in file solr.cmd from \bin folder)

[Linux] update SOLR_START_OPTS=(...) adding "-Dlog4j2.formatMsgNoLookups=true" whereever you want inside brackets
(in file solr from /bin folder)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests