Re: Release of libxml2 2.9.13

--===============2622288790749328091==
Content-Type: multipart/alternative; boundary="000000000000d611ec05d8879e60"

--000000000000d611ec05d8879e60
Content-Type: text/plain; charset="UTF-8"

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 <[email protected]> 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
>
>
>
>

--000000000000d611ec05d8879e60
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Nick,<div><br></div><div>I understand and appreciate th=
e general difficulty of scoring severity without some application-specific =
context. And I don&#39;t disagree with your take on CVSS scores for librari=
es.</div><div><br></div><div>However, downstream maintainers may want to is=
sue our own security advisories so that=C2=A0our users can make an informed=
 decision about mitigation. When there is a published CVE (whether you crea=
ted it or not), expectations=C2=A0are usually higher with respect to inform=
ation disclosure and evaluation, and I&#39;d like to be able to answer any =
questions that I get.</div><div><br></div><div>In some cases, like libxslt&=
#39;s=C2=A0CVE-2021-30560, this is easy: it&#39;s possible to find a workin=
g exploit and CVSS score and I can confidently tell my users to upgrade=C2=
=A0if they&#39;re using an untrusted stylesheet. However, in the specific c=
ase of=C2=A0CVE-2022-23308 it&#39;s more challenging to determine how and w=
hether my users are impacted.</div><div><br></div><div>I&#39;m not asking s=
pecifically for a CVSS score for this vulnerability, and I&#39;m certainly =
not asking you to create a CVE for every memory fix that&#39;s found. I&#39=
;m only asking for a more accessible explanation of the conditions under wh=
ich an application might be vulnerable to this already-published CVE.</div>=
<div><br></div><div>Would this be an appropriate explanation for me to incl=
ude in my security advisory?</div><div><br></div><div>&gt; An application m=
ay be vulnerable to a denial-of-service attack if it parses an untrusted do=
cument with parse options `DTDVALID` on, and `NOENT` off.<br><br>Again, tha=
nks for the work you&#39;re doing. I hope you understand I&#39;m not trying=
 to be pedantic, I&#39;m only trying to keep my users informed and give the=
m good advice.</div><div><br></div></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Sun, Feb 20, 2022 at 6:09 PM Nick Wel=
lnhofer &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 20=
/02/2022 20:50, Mike Dalessio wrote:<br>
&gt; Is there any additional information about CVE-2022-23308 (other than t=
he <br>
&gt; commit log) that would=C2=A0help downstream projects triage? Was there=
 a CVSS score <br>
&gt; calculated or severity assigned?<br>
<br>
In this case, the CVE record is managed by a third party. It should be made=
 <br>
public soon, but I have no influence on that. In my personal opinion, the <=
br>
whole CVE system is severely flawed with regard to OSS projects. Basically,=
 <br>
anyone can request a CVE ID for arbitrary projects without having to <br>
coordinate with maintainers.<br>
<br>
It&#39;s often hard, if not impossible, to come up with meaningful CVSS sco=
res for <br>
vulnerabilities in software libraries. If there&#39;s a flaw in a certain l=
ibrary <br>
function, it really depends on how this function used by downstream project=
s. <br>
If you look at major Linux distros, there are 500+ projects with a direct <=
br>
dependency on libxml2, and thousands with an indirect dependency. Most of t=
hem <br>
don&#39;t call the vulnerable functions at all, some others are libraries <=
br>
themselves, so it all depends on their users.<br>
<br>
There are quite a few preconditions to be met to trigger a use-after-free i=
n <br>
this particular case, so I&#39;m not overly concerned. Even then, it seems =
<br>
anything but trivial come up with a serious exploit. But I&#39;m not really=
 an <br>
expert and you never can tell without auditing tens or hundreds of downstre=
am <br>
projects. Besides, I only have limited resources to assess the impact of <b=
r>
security issues, and it&#39;s always possible that I missed something.<br>
<br>
Note that for some reason, GitLab truncates the commit message after ~1000 =
<br>
characters with no obvious way to expand it, at least on <a href=3D"http://=
gitlab.gnome.org" rel=3D"noreferrer" target=3D"_blank">gitlab.gnome.org</a>=
. You <br>
can see the full commit message on the GitHub mirror:<br>
<br>
<br>
<a href=3D"https://github.com/GNOME/libxml2/commit/652dd12a858989b14eed4e84=
e453059cd3ba340e" rel=3D"noreferrer" target=3D"_blank">https://github.com/G=
NOME/libxml2/commit/652dd12a858989b14eed4e84e453059cd3ba340e</a><br>
<br>
Nick<br>
<br>
<br>
<br>
</blockquote></div>

--000000000000d611ec05d8879e60--

--===============2622288790749328091==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
[email protected]
https://mail.gnome.org/mailman/listinfo/xml

--===============2622288790749328091==--