Re: [xml] Release of libxml2 2.9.13

[Mike Dalessio <mike dalessio gmail com>]

Hi Nick,

I understand and appreciate the general difficulty of scoring severity without some application-specific context. And I don't disagree with your take on CVSS scores for libraries.

However, downstream maintainers may want to issue our own security advisories so that our users can make an informed decision about mitigation. When there is a published CVE (whether you created it or not), expectations are usually higher with respect to information disclosure and evaluation, and I'd like to be able to answer any questions that I get.

In some cases, like libxslt's CVE-2021-30560, this is easy: it's possible to find a working exploit and CVSS score and I can confidently tell my users to upgrade if they're using an untrusted stylesheet. However, in the specific case of CVE-2022-23308 it's more challenging to determine how and whether my users are impacted.

I'm not asking specifically for a CVSS score for this vulnerability, and I'm certainly not asking you to create a CVE for every memory fix that's found. I'm only asking for a more accessible explanation of the conditions under which an application might be vulnerable to this already-published CVE.

Would this be an appropriate explanation for me to include in my security advisory?

> An application may be vulnerable to a denial-of-service attack if it parses an untrusted document with parse options `DTDVALID` on, and `NOENT` off.

Again, thanks for the work you're doing. I hope you understand I'm not trying to be pedantic, I'm only trying to keep my users informed and give them good advice.

On Sun, Feb 20, 2022 at 6:09 PM Nick Wellnhofer <wellnhofer aevum de> wrote:

On 20/02/2022 20:50, Mike Dalessio wrote:
> Is there any additional information about CVE-2022-23308 (other than the
> commit log) that would help downstream projects triage? Was there a CVSS score
> calculated or severity assigned?

In this case, the CVE record is managed by a third party. It should be made
public soon, but I have no influence on that. In my personal opinion, the
whole CVE system is severely flawed with regard to OSS projects. Basically,
anyone can request a CVE ID for arbitrary projects without having to
coordinate with maintainers.

It's often hard, if not impossible, to come up with meaningful CVSS scores for
vulnerabilities in software libraries. If there's a flaw in a certain library
function, it really depends on how this function used by downstream projects.
If you look at major Linux distros, there are 500+ projects with a direct
dependency on libxml2, and thousands with an indirect dependency. Most of them
don't call the vulnerable functions at all, some others are libraries
themselves, so it all depends on their users.

There are quite a few preconditions to be met to trigger a use-after-free in
this particular case, so I'm not overly concerned. Even then, it seems
anything but trivial come up with a serious exploit. But I'm not really an
expert and you never can tell without auditing tens or hundreds of downstream
projects. Besides, I only have limited resources to assess the impact of
security issues, and it's always possible that I missed something.

Note that for some reason, GitLab truncates the commit message after ~1000
characters with no obvious way to expand it, at least on gitlab.gnome.org. You
can see the full commit message on the GitHub mirror:


https://github.com/GNOME/libxml2/commit/652dd12a858989b14eed4e84e453059cd3ba340e

Nick