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 <wellnho...@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 > > > >
_______________________________________________ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
