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. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A potential XML External Entity (XXE) vulnerability exists in Blink’s XSLT implementation due to missing security callback initialization and unescaped comment serialization. This could allow a malicious website to read local files from the renderer process’s filesystem on platforms like Android.

Affected files:

• third_party/blink/renderer/core/xml/xsl_style_sheet_libxslt.cc
• third_party/blink/renderer/core/editing/serializers/markup_formatter.cc
• third_party/blink/renderer/core/xml/xslt_processor_libxslt.cc
• third_party/blink/renderer/core/xml/parser/xml_document_parser.cc

Estimated timestamp from git blame: 2013-08-23

Summary

A potential vulnerability in Blink’s XSLT implementation may allow for XML External Entity (XXE) attacks, enabling an attacker to read files from the renderer’s local filesystem. The issue stems from a failure to initialize Blink’s secure libxml2 IO callbacks before parsing a stylesheet, combined with a lack of escaping when serializing XML comments.

Root Cause Analysis

Blink typically protects against libxml2’s default behavior of loading external entities by registering specialized IO callbacks (e.g., MatchFunc, OpenFunc) via EnsureLibXMLInitialized() in third_party/blink/renderer/core/xml/parser/xml_document_parser.cc. These callbacks enforce security policies like same-origin checks and prohibit direct filesystem access.

However, XSLStyleSheet::ParseString in third_party/blink/renderer/core/xml/xsl_style_sheet_libxslt.cc fails to call EnsureLibXMLInitialized(). If ParseString is invoked in a fresh renderer process before any other XML parsing has occurred, libxml2 will use its default, insecure IO handlers. On Android, the renderer’s seccomp policy explicitly allows the openat syscall (see sandbox/linux/seccomp-bpf-helpers/baseline_policy_android.cc), allowing these default handlers to read local files.

Furthermore, the XSLTProcessor.importStylesheet() API uses CreateMarkup to serialize the provided DOM tree. In third_party/blink/renderer/core/editing/serializers/markup_formatter.cc, the AppendComment method (line 274) does not escape the comment closer -->, allowing an attacker to inject a malicious DTD directly into the serialized XML string that ParseString then parses.

Potential Attack Steps

An attacker could potentially trigger this vulnerability using the following steps:

1. Create a malicious XML document containing a Comment node with a payload like: --> <!DOCTYPE x [<!ENTITY f SYSTEM "file:///proc/self/status">]> <xsl:stylesheet ...> ... &f; ... </xsl:stylesheet> <!-- .
2. Call XSLTProcessor.importStylesheet(malicious_doc). This triggers the insecure serialization in AppendComment and the subsequent vulnerable parse in ParseString.
3. Call transformToFragment() or transformToDocument(). The XSLT engine will execute the injected stylesheet, resolving the &f; entity to the contents of /proc/self/status using libxml2’s default IO handlers.
4. Read the leaked data from the resulting fragment or document’s text content.

Impact

This is an information disclosure vulnerability. On Android, an attacker can potentially read any file accessible to the renderer process (e.g., /proc/self/maps, /proc/self/status), which can be used to leak ASLR offsets and facilitate a full renderer exploit chain. On other platforms like Linux, while the logic flaw exists, seccomp typically blocks the open() syscall, mitigating direct file access.

Suggested Fix

1. In XSLStyleSheet::ParseString, ensure EnsureLibXMLInitialized() is called before any libxml2 parsing functions.
2. In MarkupFormatter::AppendComment, implement proper escaping or validation to ensure that the comment data does not contain the --> sequence.

Evaluated with Chrome root at commit: b3153093eb3c78c3e88ccf562bcbc20437a04b0e

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

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.