Thanks a lot for forking the project. I noticed there is another known “open issue” which has no CVE assigned, but given that the other CVEs expect untrusted config entries, it might be in scope as well? Apache claims that the XML parser is vulnerable to external includes (xxe, billion laughters, ssrf). Should we enable secure processing and restrict remote protocols? If so.. should we do it unconditional or with a system property in case someone used really an external entity?
From the website:
Other issues of note Log4j 1 doesn't restrict DTD entities in log4j.xml. Users should be careful to ensure any entities specified are correct and secure. BTW I mentioned on Twitter the RedHat backports, it looks like all of them are addressed in reload4j (some slightly different), they can be seen here for example https://git.centos.org/rpms/log4j/commits/c7 -- http://bernd.eckenfels.net
This is a very good point. Something like this should be added to the DOMConfigurator class: dbf = DocumentBuilderFactory.newInstance(); dbf .setFeature("http://apache.org/xml/features/nonvalidating/load-dtd-grammar", false); dbf .setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false); /Robert _______________________________________ Robert Olofsson, Sweden http://www.unlogic.se Den 2022-01-24 kl. 14:31, skrev Bernd Eckenfels:
Thanks a lot for forking the project.
I noticed there is another known “open issue” which has no CVE assigned, but given that the other CVEs expect untrusted config entries, it might be in scope as well?
Apache claims that the XML parser is vulnerable to external includes (xxe, billion laughters, ssrf). Should we enable secure processing and restrict remote protocols? If so.. should we do it unconditional or with a system property in case someone used really an external entity?
From the website:
Other issues of note
Log4j 1 doesn't restrict DTD entities in log4j.xml. Users should be careful to ensure any entities specified are correct and secure.
BTW I mentioned on Twitter the RedHat backports, it looks like all of them are addressed in reload4j (some slightly different), they can be seen here for example https://git.centos.org/rpms/log4j/commits/c7 -- http://bernd.eckenfels.net
_______________________________________________ reload4j mailing list reload4j@qos.ch http://mailman.qos.ch/cgi-bin/mailman/listinfo/reload4j
Hi Bernd, Thank you for your feedback. Can you please create a github issue for the XXE vulnerability? Note that the Jira for reload4j (and only reload4j) moved to github. -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 1/24/2022 2:31 PM, Bernd Eckenfels wrote:
Thanks a lot for forking the project.
I noticed there is another known “open issue” which has no CVE assigned, but given that the other CVEs expect untrusted config entries, it might be in scope as well?
Apache claims that the XML parser is vulnerable to external includes (xxe, billion laughters, ssrf). Should we enable secure processing and restrict remote protocols? If so.. should we do it unconditional or with a system property in case someone used really an external entity?
From the website:
Other issues of note
Log4j 1 doesn't restrict DTD entities in log4j.xml. Users should be careful to ensure any entities specified are correct and secure.
BTW I mentioned on Twitter the RedHat backports, it looks like all of them are addressed in reload4j (some slightly different), they can be seen here for example https://git.centos.org/rpms/log4j/commits/c7 <https://git.centos.org/rpms/log4j/commits/c7> -- http://bernd.eckenfels.net
participants (3)
-
Bernd Eckenfels -
Ceki Gülcü -
Robert Olofsson