For CVE-2019-17571, it looks like log4j has to be actively listening on a tcp/udp socket, accepting logs via network. The proof of concept linked below illustrates this.michnovka wrote:Hi,
we were testing this yesterday a lot and found that the Log4J version Zimbra uses (1.2.6 it seems for many bulds, at least since 8.4) is not affected.
We did try to confirm the exploit by using the suggested approach at https://www.lunasec.io/docs/blog/log4j-zero-day/ and indeed we found DNS records at http://dnslog.cn/ being looked up. This startled us and frightened, as it seemed it does perform some connection.
However we did some digging then with TCP dump to see if LDAP connection was made, or what was actually going on. Turns out that it is the anti-spam filters we have set up, that look through message contents and test every single URL they can find:Therefore we are confident that Zimbra version 8.8.15.P28 is not affected.Code: Select all
23:47:01.010464 IP RE.DA.CT.ED.34391 > 8.8.8.8.domain: 59229+ [1au] A? dnslog.cn.multi.surbl.org. (54) 23:47:01.010673 IP RE.DA.CT.ED.34391 > 8.8.8.8.domain: 31930+ [1au] A? dnslog.cn.multi.uribl.com. (54) 23:47:01.010916 IP RE.DA.CT.ED.34391 > 8.8.8.8.domain: 32871+ [1au] A? dnslog.cn.dob.sibl.support-intelligence.net. (72) 23:47:01.011180 IP 8.8.8.8.domain > RE.DA.CT.ED.34391: 64690 1/0/1 A 127.0.0.1 (72) 23:47:01.011279 IP RE.DA.CT.ED.34391 > 8.8.8.8.domain: 5885+ [1au] A? dnslog.cn.dbl.spamhaus.org. (55) 23:47:01.011623 IP RE.DA.CT.ED.34391 > 8.8.8.8.domain: 19962+ [1au] NS? dnslog.cn. (38) 23:47:01.011798 IP RE.DA.CT.ED.34391 > 8.8.8.8.domain: 42471+ [1au] A? utx82b.dnslog.cn. (45)
---
That being said, I did discover this: https://nvd.nist.gov/vuln/detail/CVE-2019-17571
This is another remote code execution CVE affecting log4j and here the version used by Zimbra is indeed vulnerable. The severity of this is critical, the question remains, whether it is exploitable or not. I want to remain calm, as this has been out for months and no new patch was published by Zimbra, so I would expect they know about this and concluded it is not exploitable in Zimbra's use case. However I would very much welcome confirmation of this hypothesis, given the severity of this CVE.
Thanks!
I'm pretty sure Zimbra doesn't have this configured, (though I can't check my server right this second to confirm). Even if it does, mitigation for it seems to consist of firewalling the open port from public traffic, which mine already would be.
https://www.whitesourcesoftware.com/vul ... 2019-17571
I'm not worried about it if my interpretation is correct, but if anyone thinks I'm wrong or missing something please let me know!