Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports without the Chrome Security team.

Overview: A re-entrancy vulnerability exists in Blink’s XML parser where synchronous script execution can lead to nested calls to libxml2’s xmlParseChunk on the same context. This allows an inner parse frame to reallocate internal buffers while an outer frame holds raw pointers to them. When the outer frame resumes, it accesses freed memory, potentially leading to an out-of-bounds write and remote code execution in the renderer.

Affected files:

• third_party/blink/renderer/core/script/xml_parser_script_runner.cc
• third_party/blink/renderer/core/xml/parser/xml_document_parser.cc
• third_party/libxml/src/parser.c
• third_party/blink/renderer/core/loader/document_loader.cc
• third_party/blink/renderer/platform/loader/fetch/url_loader/navigation_body_loader.cc
• third_party/blink/renderer/core/frame/local_frame.cc
• third_party/blink/renderer/core/page/chrome_client.cc

Estimated timestamp from git blame: 2023-11-02

Summary

There is a potential Use-After-Free (UAF) and Out-Of-Bounds (OOB) write vulnerability in Blink’s integration with libxml2. The issue stems from the fact that XMLParserScriptRunner can execute scripts synchronously in a way that bypasses network-level re-entrancy guards. This allows an attacker to force a re-entrant call to xmlParseChunk on the same xmlParserCtxt. The inner parse can reallocate the parser’s namespace stack (pushTab), invalidating raw pointers held by the suspended outer parse frame.

Note: The following analysis is based on code inspection and traces. These are suggested/potential steps to trigger the issue, as our tooling does not yet have the ability to run a live proof-of-concept.

Technical Details

1. Bypassing Re-entrancy Guards: When an external XML script finishes loading, XMLParserScriptRunner::PendingScriptFinished synchronously calls XMLDocumentParser::ResumeParsing(). Because this originates from a script loading callback rather than a NavigationBodyLoader network read, standard re-entrancy guards like is_in_on_readable_ and in_commit_data_ are false.
2. Nested Message Loop: If the resumed parsing executes an inline script that calls alert(1), it triggers ChromeClient::OpenJavaScriptDialog, which creates a ScopedPagePauser. This spins a nested message loop.
3. Synchronous Loader Resumption: When the user dismisses the dialog, the ScopedPagePauser destructor calls Page::SetPaused(false). This synchronously propagates down to NavigationBodyLoader::SetDefersLoading(kNone), which immediately calls OnReadable() to read pending Mojo data.
4. Re-entrant Parse: Because the re-entrancy guards were false (as established in step 1), OnReadable successfully reads the next chunk of XML data and passes it to XMLDocumentParser::Append, leading to an inner, re-entrant call to xmlParseChunk on the identical xmlParserCtxt object.
5. Use-After-Free in libxml2: The suspended outer parse frame is stopped inside xmlParseEndTag2 (third_party/libxml/src/parser.c), holding a raw const xmlStartTag *tag pointer to the ctxt->pushTab buffer. If the inner parse processes deeply nested namespace tags, nameNsPush calls xmlRealloc on ctxt->pushTab, freeing the memory the outer frame is pointing to.
6. OOB Write: When the inner parse returns, the outer xmlParseEndTag2 resumes. It accesses tag->nsNr from the freed memory and passes it to xmlParserNsPop. If an attacker controls this memory and supplies a large positive integer for nsNr, it causes an integer underflow in xmlParserNsPop’s loop bounds. This leads to negative-index OOB reads and a subsequent OOB heap write (bucket->index = extra->oldIndex), providing a strong primitive for Remote Code Execution.

Potential Steps to Reproduce

An attacker could potentially trigger this by serving an application/xhtml+xml document using chunked transfer encoding:

1. Send Chunk A: <script src="ext.js"></script>. This pauses the XML parser to wait for the external script.
2. Send Chunk B: <a xmlns:p="u"><script>alert(1)</script>. This chunk is safely buffered in pending_src_ because the parser is paused.
3. Send Chunk C: A payload of deeply nested <foo xmlns:a="1"> tags followed by an inline <script>groom()</script>. This sits unread in the Mojo data pipe.
4. Finish ext.js: The browser finishes loading the external script. The callback resumes parsing and processes Chunk B.
5. Trigger Pauser: The alert(1) in Chunk B executes, creating the ScopedPagePauser.
6. Dismiss Dialog: When the dialog is dismissed, NavigationBodyLoader synchronously reads Chunk C, triggering the re-entrant inner parse.
7. Reallocation and Grooming: The deeply nested tags in Chunk C force ctxt->pushTab to reallocate, freeing the old buffer. The groom() script allocates memory to reclaim the freed buffer and writes a controlled nsNr payload.
8. Exploitation: The inner parse completes, the outer parse resumes, dereferences the dangling pointer to read the attacker’s nsNr, and executes the OOB write.

Suggested Fix

To prevent this vulnerability, XMLParserScriptRunner::PendingScriptFinished should avoid resuming the parser synchronously on the current call stack. It should instead use PostTask to schedule the resumption, ensuring the C++ stack is unwound and preventing cooperative re-entrancy. This approach is already successfully used by the HTML parser (HTMLParserScriptRunner::PendingScriptFinished).

Alternatively, XMLDocumentParser could maintain a strict internal re-entrancy boolean guard that CHECKs or safely drops nested calls to Append() or ResumeParsing() while a parse chunk is actively executing.

Evaluated with Chrome root at commit: 096fc8fdbfacf2546485756d03f160a3d04fcc9b

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.