Multiple security issues in ezxml

[sebastic]

As reported by Moritz Muehlenhoff in Debian Bug #989363:

Multiple security issues were found in ezxml, which mapcache bundles:

CVE-2021-31598: https://sourceforge.net/p/ezxml/bugs/28/

CVE-2021-31348 / CVE-2021-31347: https://sourceforge.net/p/ezxml/bugs/27/

CVE-2021-31229: https://sourceforge.net/p/ezxml/bugs/26/

CVE-2021-30485: https://sourceforge.net/p/ezxml/bugs/25/

CVE-2021-26222: https://sourceforge.net/p/ezxml/bugs/22/

CVE-2021-26221: https://sourceforge.net/p/ezxml/bugs/21/

CVE-2021-26220: https://sourceforge.net/p/ezxml/bugs/23/

CVE-2019-20202: https://sourceforge.net/p/ezxml/bugs/17

CVE-2019-20201 https://sourceforge.net/p/ezxml/bugs/16

CVE-2019-20200: https://sourceforge.net/p/ezxml/bugs/19

CVE-2019-20199: https://sourceforge.net/p/ezxml/bugs/18

CVE-2019-20198: https://sourceforge.net/p/ezxml/bugs/20

CVE-2019-20007: https://sourceforge.net/p/ezxml/bugs/13

CVE-2019-20006: https://sourceforge.net/p/ezxml/bugs/15

CVE-2019-20005: https://sourceforge.net/p/ezxml/bugs/14

Another ezxml issue as reported in Debian Bug #1014389:

CVE-2022-30045[0]:
| An issue was discovered in libezxml.a in ezXML 0.8.6. The function
| ezxml_decode() performs incorrect memory handling while parsing
| crafted XML files, leading to a heap out-of-bounds read.

[0] https://security-tracker.debian.org/tracker/CVE-2022-30045
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30045

[tbonfort]

AFAIK, ezxml is only used to parse the configuration file at startup, and thus these vulnerabilities are not exploitable remotely. A malicious mapcache.xml could be crafted to gain superuser privileges (as the xml parsing is done as root before apache forks to an unpriviledged user), but then again the apache conf files (which mapcache.xml is when using mod_mapcache) should already only be writable only by root. If the ezxml were to be updated to patch these issues, mapcache should of course update asap, but I'm not very confident that will happen soon given ezxml's recent activity.

[sdlime]

Could it make sense to remove the dependency on ezxml in favor of another XML reader?

[sebastic]

libxml2 is a much healthier project.

[sebastic]

Can MapCache move away from ezxml to libxml2 or (and embedded copy of) tinyxml2?

[sdlime]

I agree this would be a very good idea. Question is who is available to do that work.

[sebastic]

If no one is available, how much funding will be required to commission the work to move away from ezxml?

[tbonfort]

It might also make sense to use libapr's xml parsing capabilities as that won't lead to adding another dependency