Re: Release of libxml2 2.9.13

--===============5396993002916502498==
Content-Type: multipart/alternative; boundary="0000000000000ffa7e05d889f492"

--0000000000000ffa7e05d889f492
Content-Type: text/plain; charset="UTF-8"

This is very helpful. Thanks as always, Nick.

On Mon, Feb 21, 2022 at 11:42 AM Nick Wellnhofer <[email protected]>
wrote:

> On 21/02/2022 14:57, Mike Dalessio wrote:
> > 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.
>
>  From my limited analysis, there are two scenarios:
>
> 1. When using the reader API (xmlreader.h, xmlTextReader)
>
>    Conditions:
>
>    - Create a reader with parser option XML_PARSE_DTDVALID (or "parser
>      property" XML_PARSER_VALIDATE) but without parser option
> XML_PARSE_NOENT
>      (XML_PARSER_SUBST_ENTITIES)
>    - Parse an untrusted document
>
>    Impact:
>
>    - Crash (DoS)
>    - Memory disclosure via error channel
>
> 2. When using another parser API
>
>    Conditions:
>
>    - Parse an untrusted document with XML_PARSE_DTDVALID but without
>      XML_PARSE_NOENT
>    - Delete a portion of the resulting document
>    - Call xmlGetID on the document
>
>    Potential impact:
>
>    - Crash (DoS)
>    - Arbitrary memory disclosure
>    - Arbitrary code execution
>
> > 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.
>
> No, that's understating the severity. As I tried to explain, it's
> impossible
> to assess the severity without auditing each and every downstream project.
> Since clever exploitation of use-after-free errors can result in code
> execution, I have to assume the worst case if you force me to make a
> general
> statement.
>
> DISCLAIMER: I make no guarantees regarding the accuracy and completeness
> of my
> statements above.
>
> Nick
>

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

<div dir=3D"ltr">This is very helpful. Thanks as always, Nick.</div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Feb 2=
1, 2022 at 11:42 AM Nick Wellnhofer &lt;<a href=3D"mailto:wellnhofer@aevum.=
de">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">On 21/02/2022 14:57, Mike Dalessio wrote:<br>
&gt; I&#39;m not asking specifically for a CVSS score for this vulnerabilit=
y, and I&#39;m <br>
&gt; certainly not asking you to create a CVE for every memory fix that&#39=
;s found. <br>
&gt; I&#39;m only asking for a more accessible explanation of the condition=
s under <br>
&gt; which an application might be vulnerable to this already-published CVE=
.<br>
<br>
=C2=A0From my limited analysis, there are two scenarios:<br>
<br>
1. When using the reader API (xmlreader.h, xmlTextReader)<br>
<br>
=C2=A0 =C2=A0Conditions:<br>
<br>
=C2=A0 =C2=A0- Create a reader with parser option XML_PARSE_DTDVALID (or &q=
uot;parser<br>
=C2=A0 =C2=A0 =C2=A0property&quot; XML_PARSER_VALIDATE) but without parser =
option XML_PARSE_NOENT<br>
=C2=A0 =C2=A0 =C2=A0(XML_PARSER_SUBST_ENTITIES)<br>
=C2=A0 =C2=A0- Parse an untrusted document<br>
<br>
=C2=A0 =C2=A0Impact:<br>
<br>
=C2=A0 =C2=A0- Crash (DoS)<br>
=C2=A0 =C2=A0- Memory disclosure via error channel<br>
<br>
2. When using another parser API<br>
<br>
=C2=A0 =C2=A0Conditions:<br>
<br>
=C2=A0 =C2=A0- Parse an untrusted document with XML_PARSE_DTDVALID but with=
out<br>
=C2=A0 =C2=A0 =C2=A0XML_PARSE_NOENT<br>
=C2=A0 =C2=A0- Delete a portion of the resulting document<br>
=C2=A0 =C2=A0- Call xmlGetID on the document<br>
<br>
=C2=A0 =C2=A0Potential impact:<br>
<br>
=C2=A0 =C2=A0- Crash (DoS)<br>
=C2=A0 =C2=A0- Arbitrary memory disclosure<br>
=C2=A0 =C2=A0- Arbitrary code execution<br>
<br>
&gt; Would this be an appropriate explanation for me to include in my secur=
ity <br>
&gt; advisory?<br>
&gt; <br>
&gt;=C2=A0 &gt; An application may be vulnerable to a denial-of-service att=
ack if it parses <br>
&gt; an untrusted document with parse options `DTDVALID` on, and `NOENT` of=
f.<br>
<br>
No, that&#39;s understating the severity. As I tried to explain, it&#39;s i=
mpossible <br>
to assess the severity without auditing each and every downstream project. =
<br>
Since clever exploitation of use-after-free errors can result in code <br>
execution, I have to assume the worst case if you force me to make a genera=
l <br>
statement.<br>
<br>
DISCLAIMER: I make no guarantees regarding the accuracy and completeness of=
 my <br>
statements above.<br>
<br>
Nick<br>
</blockquote></div>

--0000000000000ffa7e05d889f492--

--===============5396993002916502498==
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

--===============5396993002916502498==--