[reload4j] Secure XML Parser config?

[Robert Olofsson]

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 at qos.ch
> http://mailman.qos.ch/cgi-bin/mailman/listinfo/reload4j
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/reload4j/attachments/20220124/a682b202/attachment.html>