Fedora has issued an advisory today (April 18): https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/O2AHHHTXMCLOVEDOB7VUJWRWH5RXZTEG/ The issues are fixed upstream in 2.10.4: https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.10.4 Mageia 8 is also affected.
Blocks: (none) => 31231Status comment: (none) => Fixed upstream in 2.10.4Whiteboard: (none) => MGA8TOO
libxml2 has no obvious maintainer, so assigning this globally. CC'ing ns80 who did a CVE update of it not so long ago.
Assignee: bugsquad => pkg-bugsCC: (none) => nicolas.salguero
Suggested advisory: ======================== The updated packages fix security vulnerabilities: NULL dereference in xmlSchemaFixupComplexType. (CVE-2023-28484) Hashing of empty dict strings isn't deterministic. (CVE-2023-29469) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-28484 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-29469 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/O2AHHHTXMCLOVEDOB7VUJWRWH5RXZTEG/ ======================== Updated packages in core/updates_testing: ======================== lib(64)xml2_2-2.9.10-7.7.mga8 lib(64)xml2-devel-2.9.10-7.7.mga8 libxml2-python3-2.9.10-7.7.mga8 libxml2-utils-2.9.10-7.7.mga8 from SRPM: libxml2-2.9.10-7.7.mga8.src.rpm
CVE: (none) => CVE-2023-28484, CVE-2023-29469Status: NEW => ASSIGNEDAssignee: pkg-bugs => qa-bugsStatus comment: Fixed upstream in 2.10.4 => (none)Whiteboard: MGA8TOO => (none)Version: Cauldron => 8Source RPM: libxml2-2.10.3-1.mga9.src.rpm => libxml2-2.9.10-7.6.mga8.src.rpm
Ooops! I forgot bug 31231. Suggested advisory: ======================== The updated packages fix security vulnerabilities: NULL Pointer Dereference allows attackers to cause a denial of service (or application crash). This only applies when lxml is used together with libxml2 2.9.10 through 2.9.14. libxml2 2.9.9 and earlier are not affected. It allows triggering crashes through forged input data, given a vulnerable code sequence in the application. The vulnerability is caused by the iterwalk function (also used by the canonicalize function). Such code shouldn't be in wide-spread use, given that parsing + iterwalk would usually be replaced with the more efficient iterparse function. However, an XML converter that serialises to C14N would also be vulnerable, for example, and there are legitimate use cases for this code sequence. If untrusted input is received (also remotely) and processed via iterwalk function, a crash can be triggered. (CVE-2022-2309) NULL dereference in xmlSchemaFixupComplexType. (CVE-2023-28484) Hashing of empty dict strings isn't deterministic. (CVE-2023-29469) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2309 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-28484 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-29469 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/O2AHHHTXMCLOVEDOB7VUJWRWH5RXZTEG/ https://ubuntu.com/security/notices/USN-5760-1 https://bugs.mageia.org/show_bug.cgi?id=31231
Created attachment 13787 [details] Simplified PoC script for CVE-2022-2309 Simply run this with python3. If the issue is fixed the script will report the syntax error in the data and exit without a segfault.
CC: (none) => tarazed25
Mageia8, x64 *Before update* CVE-2022-2309 https://huntr.dev/bounties/8264e74f-edda-4c40-9956-49de635105ba/ $ python poc_issue1.py parse_and_canonicalize first_input: EndTag: '</' not found, line 3, column 1 (<string>, line 3) parse_and_canonicalize second_input: $ This looks like a tidy result and no segfault - so issue had already been corrected. Previous tests can be traced back to Herman. Going with those. No issues before update. *After update* $ python poc_issue1.py parse_and_canonicalize first_input: EndTag: '</' not found, line 3, column 1 (<string>, line 3) parse_and_canonicalize second_input: $ xmllint --auto <?xml version="1.0"?> <info>abc</info> $ xmlcatalog --create <?xml version="1.0"?> <!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN" "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd"> <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"/> $ strace -o chromium.trace chromium-browser <Viewed several of the XML file examples> $ grep xml2 chromium.trace openat(AT_FDCWD, "/lib64/libxml2.so.2", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib64/libxml2.so.2.9.10", O_RDONLY|O_CLOEXEC) = 95 xmllint has a large number of options. The basic one is parsing the input for errors. Tried it on a vlc channels.xspf file used for TV viewing and it returned a copy of the file with no errors, as expected. This all looks good.
Whiteboard: (none) => MGA8-64-OK
Validating. Advisory to use is in comment 3.
CC: (none) => andrewsfarm, sysadmin-bugsKeywords: (none) => validated_update
CC: (none) => davidwhodginsKeywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2023-0157.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED