Re: [xml] Release of libxml2 2.9.13

[Mike Dalessio <mike dalessio gmail com>]

This is very helpful. Thanks as always, Nick.

On Mon, Feb 21, 2022 at 11:42 AM Nick Wellnhofer <wellnhofer aevum de> 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