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-44228 Joseph Tam <jtam.home at 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-cve-2021-44228 > > > Joseph Tam <jtam.home at 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
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-cve-2021-44228 > > > Joseph Tam <jtam.home at gmail.com>-- Alessio Cecchi Postmaster @ http://www.qboxmail.it https://www.linkedin.com/in/alessice -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20211215/f70ca033/attachment.htm>