Re: [xml] Release of libxml2 2.9.13

[Nick Wellnhofer <wellnhofer aevum de>]

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