Can dovecot be leveraged to exploit Solr/Log4shell?
I'm surprised I haven't seen this mentioned yet.
An internet red alert went out Friday on a new zero-day exploit. It is an input validation problem where Java's Log4j module can be instructed via a specially crafted string to fetch and execute code from a remote LDAP server. It has been designated the Log4shell exploit (CVE-2021-44228).
Although I don't use it, I immediately thought of Solr, which provides some dovecot installations with search indexing. Can dovecot be made to pass on arbitrary loggable strings to affected versions of Solr (7.4.0-7.7.3, 8.0.0-8.11.0)?
Those running Solr to implement Dovecot FTS should look at
https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228Joseph Tam jtam.home@gmail.com
On 13/12/2021 23:43, Joseph Tam wrote:
I'm surprised I haven't seen this mentioned yet.
An internet red alert went out Friday on a new zero-day exploit. It is an input validation problem where Java's Log4j module can be instructed via a specially crafted string to fetch and execute code from a remote LDAP server. It has been designated the Log4shell exploit (CVE-2021-44228).
Although I don't use it, I immediately thought of Solr, which provides some dovecot installations with search indexing. Can dovecot be made to pass on arbitrary loggable strings to affected versions of Solr (7.4.0-7.7.3, 8.0.0-8.11.0)?
Those running Solr to implement Dovecot FTS should look at
https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-c...
Joseph Tam jtam.home@gmail.com
Solr logs the search strings passed, so potentially authenticated users could log malicious strings by searching for them. I do see escaping of some special characters in the log, but not sure if that would be a sufficient mitigation. In my web server logs I see all kinds of patterns that are trying to circumvent WAF rules, so maybe someone will come up with a way of getting the malicious string into the solr log.
As Apache Solr is mentioned as one of the software that is impacted, the mitigations are to upgrade to a non vulnerable version asap and in the meantime turn off JNDI lookups.
John
Is this assuming you log at some verbose level ? What if you log at WARN or higher ?
For production it seems kind of silly to log search queries anyways.
Scott
-----Original Message----- From: dovecot dovecot-bounces@dovecot.org On Behalf Of John Fawcett Sent: Monday, December 13, 2021 8:52 PM To: dovecot@dovecot.org Subject: Re: Can dovecot be leveraged to exploit Solr/Log4shell?
On 13/12/2021 23:43, Joseph Tam wrote:
I'm surprised I haven't seen this mentioned yet.
An internet red alert went out Friday on a new zero-day exploit. It is an input validation problem where Java's Log4j module can be instructed via a specially crafted string to fetch and execute code from a remote LDAP server. It has been designated the Log4shell exploit (CVE-2021-44228).
Although I don't use it, I immediately thought of Solr, which provides some dovecot installations with search indexing. Can dovecot be made to pass on arbitrary loggable strings to affected versions of Solr (7.4.0-7.7.3, 8.0.0-8.11.0)?
Those running Solr to implement Dovecot FTS should look at
https://solr.apache.org/security.html#apache-solr-affected-by-apache-l og4j-cve-2021-44228
Joseph Tam jtam.home@gmail.com
Solr logs the search strings passed, so potentially authenticated users could log malicious strings by searching for them. I do see escaping of some special characters in the log, but not sure if that would be a sufficient mitigation. In my web server logs I see all kinds of patterns that are trying to circumvent WAF rules, so maybe someone will come up with a way of getting the malicious string into the solr log.
As Apache Solr is mentioned as one of the software that is impacted, the mitigations are to upgrade to a non vulnerable version asap and in the meantime turn off JNDI lookups.
John
This is a private message
Dovecot itself has no log4j vulnerability as Dovecot does not use Java or Log4j directly. Solr, however, does use log4j. Please see https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-c... for further information on upgrading or mitigating the issue.
Aki
On 14/12/2021 04:23 Scott qmail@top-consulting.net wrote:
Is this assuming you log at some verbose level ? What if you log at WARN or higher ?
For production it seems kind of silly to log search queries anyways.
Scott
-----Original Message----- From: dovecot dovecot-bounces@dovecot.org On Behalf Of John Fawcett Sent: Monday, December 13, 2021 8:52 PM To: dovecot@dovecot.org Subject: Re: Can dovecot be leveraged to exploit Solr/Log4shell?
On 13/12/2021 23:43, Joseph Tam wrote:
I'm surprised I haven't seen this mentioned yet.
An internet red alert went out Friday on a new zero-day exploit. It is an input validation problem where Java's Log4j module can be instructed via a specially crafted string to fetch and execute code from a remote LDAP server. It has been designated the Log4shell exploit (CVE-2021-44228).
Although I don't use it, I immediately thought of Solr, which provides some dovecot installations with search indexing. Can dovecot be made to pass on arbitrary loggable strings to affected versions of Solr (7.4.0-7.7.3, 8.0.0-8.11.0)?
Those running Solr to implement Dovecot FTS should look at
https://solr.apache.org/security.html#apache-solr-affected-by-apache-l og4j-cve-2021-44228
Joseph Tam jtam.home@gmail.com
Solr logs the search strings passed, so potentially authenticated users could log malicious strings by searching for them. I do see escaping of some special characters in the log, but not sure if that would be a sufficient mitigation. In my web server logs I see all kinds of patterns that are trying to circumvent WAF rules, so maybe someone will come up with a way of getting the malicious string into the solr log.
As Apache Solr is mentioned as one of the software that is impacted, the mitigations are to upgrade to a non vulnerable version asap and in the meantime turn off JNDI lookups.
John
This is a private message
On 14/12/2021 03:23, Scott wrote:
Is this assuming you log at some verbose level ? What if you log at WARN or higher ?
For production it seems kind of silly to log search queries anyways.
Scott
It's a pretty much standard install where most things are at INFO level. Probably could turn it down, but has not been an issue.
I think the logic behind it is much like web server logs where every single request gets a log entry.
John
Hi,
for Solr you can edit your solr.in.sh file to include:
SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"
and should be enough to prevent this vulnerability.
Ciao
Il 13/12/21 23:43, Joseph Tam ha scritto:
I'm surprised I haven't seen this mentioned yet.
An internet red alert went out Friday on a new zero-day exploit. It is an input validation problem where Java's Log4j module can be instructed via a specially crafted string to fetch and execute code from a remote LDAP server. It has been designated the Log4shell exploit (CVE-2021-44228).
Although I don't use it, I immediately thought of Solr, which provides some dovecot installations with search indexing. Can dovecot be made to pass on arbitrary loggable strings to affected versions of Solr (7.4.0-7.7.3, 8.0.0-8.11.0)?
Those running Solr to implement Dovecot FTS should look at
https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-c...
Joseph Tam jtam.home@gmail.com
-- Alessio Cecchi Postmaster @ http://www.qboxmail.it https://www.linkedin.com/in/alessice
The suggested configuration is good, and although we did some checking to ensure that dovecot escapes the search queries and usernames sent to solr, so it is not trivial to send the JNDI expansion strings to be logged by solr, it is still good idea to set this.
Aki
On 15/12/2021 09:45 Alessio Cecchi alessio@skye.it wrote:
Hi, for Solr you can edit your solr.in.sh file to include:
SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true" and should be enough to prevent this vulnerability. Ciao
Il 13/12/21 23:43, Joseph Tam ha scritto:
I'm surprised I haven't seen this mentioned yet.
An internet red alert went out Friday on a new zero-day exploit. It is an input validation problem where Java's Log4j module can be instructed via a specially crafted string to fetch and execute code from a remote LDAP server. It has been designated the Log4shell exploit (CVE-2021-44228).
Although I don't use it, I immediately thought of Solr, which provides some dovecot installations with search indexing. Can dovecot be made to pass on arbitrary loggable strings to affected versions of Solr (7.4.0-7.7.3, 8.0.0-8.11.0)?
Those running Solr to implement Dovecot FTS should look at
https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-c...
Joseph Tam jtam.home@gmail.com
-- Alessio Cecchi Postmaster @ http://www.qboxmail.it https://www.linkedin.com/in/alessice
On 15/12/2021 08:52, Aki Tuomi wrote:
The suggested configuration is good, and although we did some checking to ensure that dovecot escapes the search queries and usernames sent to solr, so it is not trivial to send the JNDI expansion strings to be logged by solr, it is still good idea to set this.
Aki
Agreed, it is worthwhile taking the advised mitigation steps regardless of the escaping done in Dovecot. Reasoning is
escaping may not be 100% foolproof - there are people out there working on bypassing such things
the search string method is not the only attack vector for SOLR. If people have SOLR exposed on an internet host, even if password protected, it doesn't mean to say that SOLR is not logging failed access attempts that can easily contain the attack string.
John
On 15.12.21 08:45, Alessio Cecchi wrote:
SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true" and should be enough to prevent this vulnerability.
Possibly not anymore, see CVE-2021-45046 ("re-opened" CVE-2021-44228 for v2 prior to 2.16.0) and CVE-2021-4104 (variant for v1, in the meantime - at least by Red Hat - downgraded to *not* be a *Remote* Code Execution (RCE) vuln) ...
Regards,
Jochen Bern Systemingenieur
Binect GmbH
participants (6)
-
Aki Tuomi
-
Alessio Cecchi
-
Jochen Bern
-
John Fawcett
-
Joseph Tam
-
Scott