[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241225181321.GA12547@openwall.com>
Date: Wed, 25 Dec 2024 19:13:21 +0100
From: Solar Designer <solar@...nwall.com>
To: Yair Mizrahi <yairm@...og.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: CVE-2024-40896 Analysis: libxml2 XXE due to type confusion
Hi,
Thank you for bringing this in here.
On Wed, Dec 25, 2024 at 11:52:06AM +0200, Yair Mizrahi wrote:
> libxml2, CVE-2024-40896, was published recently and given a "Critical"
> (9.1) severity by CISA. Interestingly - This vulnerability is a regression
> of an issue that was identified over a decade ago - CVE-2012-0037, which
> was given a "Medium" (6.5) severity.
>
> Is the massive increase in CVSS over the exact same issue justified? We
> believe that it's inflated.
I think both CVSS vectors are "buggy", and CVSS is quite poor at scoring
library code vulnerabilities.
CVE-2012-0037 NIST NVD CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
CVE-2024-40896 CISA-ADP CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
The differences are whether user interaction is required or not (can't
know that for library code, so have to assume either best or worst case)
and what impact there is (again can't know it for library code, but
these two test vectors somehow assume different impacts). Given how
poor CVSS base score is for scoring library code in general, I'm afraid
this issue would more "reasonably" (per CVSS spec) be scored 10.0 as
AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, because such exposed usage of the
library is realistic, SSRF would be a change of scope (right?), and the
worst impacts of all 3 kinds are quite possible.
What this tells us is that CVSS base scores are pretty much unusable for
ranking library and interpreter vulnerabilities. Adding temporal and
exploitability metrics may improve things, but also mostly when applied
not just to the libraries, but to their specific uses. Since this is
generally too hard, I think a future revision of CVSS should have
adjustments in the base score for issues that are not directly exposed.
I propose updating the spec to either use AC:H for them (list such
condition) or add new AV or AC type Indirect (document it as meaning the
issue isn't directly exposed as a vulnerability by the software it's
in). Indirect should be scored lower than AV:N/AC:L.
> CVE-2012-0037 allowed attackers to perform XXE attacks on vulnerable
> applications that use Raptor, an RDF parsing and serializing library, which
> uses libxml2. XXE attacks may have severe consequences, such as leakage of
> arbitrary local files from the victim machine and SSRF.
>
> The vulnerability was fixed in Raptor by parsing XML entities and making
> sure they don't contain file URIs or network URIs. A crucial part of this
> patch was letting libxml2 know not to re-parse the XML entities, as that
> would have rendered the fix ineffective.
>
> [1] In order to do this, Raptor used the "checked" field of libxml2's
> `XmlEntity` struct.
CVE-2012-0037 was (per its description) against Raptor. CVE-2024-40896
is (per its) against libxml2. As I understand from your description,
libxml2 2.11.0+ was at fault for no longer providing functionality for
Raptor to be safe, but Raptor was at fault for silently accepting that
with a code change of their own instead of sounding the alarm. Perhaps
when CVE-2012-0037 was fixed, a source code comment should have been
added to Raptor about the importance of that fix, which would have
guarded against its silent removal in 2023 (for the case of building
against libxml2 2.11.0+). So this looks to me like more of a failure by
Raptor than by libxml2.
As I understand, CVE-2024-40896 is against libxml2 because that's where
the issue is hopefully-fully addressed this time, even if the "fix" is
hardening for/against dangerous uses by third-party code such as Raptor.
It would indeed be weird to file this CVE against Raptor when fixes
would then be against libxml2. So this discrepancy is understandable,
even if unfortunate.
Disclaimer: I am not familiar with these libraries, so the above is
based on my reading of what the previous message said.
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
