Skip to content

XMLParser's own error text reaches localizedDescription verbatim: multi-line and unbounded #150

Description

@kiki830621

Problem

3.7.0 escapes and caps attacker-controlled entry names and relationship ids before they enter an error message (ZipHelper.displayName: control characters, U+2028/U+2029, zero-width and bidi controls, at most 120 scalars, rendered text capped at 480 characters). The third channel is not covered: the text XMLParser reports for a malformed part is appended verbatim.

Reproduction (verify R10, security lens)

A 37.7 KB package whose relationship id contains 9 000  references:

localizedDescription: len=441000  LF=9000
  "Line 1: xmlParseCharRef: invalid xmlChar value 1"  × 9000

Amplification 11.7×, with 9 000 real newlines — the "forged second line" property that N-S8-1 / N-S9-1 closed for entry names and ids comes back through this channel. The attacker controls only the digits and the repeat count (XML names cannot contain newlines), so arbitrary text cannot be injected, but arbitrary line count and length can.

Scope / honesty

Identical on v3.6.4 (len=441000 LF=9000) — not a regression of the cluster; the PR never claimed to cover parser text. 3.7.0's CHANGELOG states this limitation and points here.

Fix sketch

Route parser error text through ZipHelper.displayName (or keep only the parser's error code and line/column, which is what describeWithoutPaths already does for file errors).

Refs #137, #139. Surfaced by verify R10 of PR #141 (security NEW-S10-2).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions