[
https://issues.apache.org/jira/browse/AVRO-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18101443#comment-18101443
]
ASF subversion and git services commented on AVRO-4313:
-------------------------------------------------------
Commit 44f7aa35a6b90ac7d39ef0e68dad706561235941 in avro's branch
refs/heads/dependabot/uv/lang/py/setuptools-83.0.0 from Ismaël Mejía
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=44f7aa35a6 ]
AVRO-4313: [java] Tighten javaAnnotation string-literal validation in
SpecificCompiler (#3892)
* AVRO-4313: [java] Tighten javaAnnotation string-literal validation in
SpecificCompiler
The string-literal grammar used to validate javaAnnotation values accepted
an unescaped quote inside the literal body, letting a single literal span
past its intended closing quote and absorb surrounding tokens. Constrain the
body to recognized escape sequences or characters that are not a quote,
backslash, or line terminator, and add a regression test.
* AVRO-4313: Exclude all line terminators from annotation string literals
Also reject NEL, LS and PS in addition to CR and LF so an annotation value
cannot span multiple lines in the generated source.
* AVRO-4313: Make injection regression test robust to multiple outputs
Assert the injection payload is absent from every generated file and the
valid annotation is emitted in at least one, rather than requiring it in
each output file.
> [java] javaAnnotation values can inject arbitrary Java code into generated
> sources
> ----------------------------------------------------------------------------------
>
> Key: AVRO-4313
> URL: https://issues.apache.org/jira/browse/AVRO-4313
> Project: Apache Avro
> Issue Type: Bug
> Components: java
> Affects Versions: 1.11.5, 1.12.1
> Reporter: Ismaël Mejía
> Assignee: Ismaël Mejía
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.13.0, 1.12.2
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> When Avro generates Java classes from a schema, the value of the
> {{javaAnnotation}} schema property is written *as-is* into the generated
> source code. To keep this safe, {{SpecificCompiler}} validates each value
> with a regular expression that is supposed to accept only a Java annotation
> shape: an identifier optionally followed by a parameter list, e.g.
> {code:java}
> @Deprecated
> @SuppressWarnings("unchecked")
> {code}
> The validation regex was too permissive. The part that matches a quoted
> string (for example {{"unchecked"}}) allowed an *unescaped double-quote
> inside the string body*. As a result, a single "string literal" could run
> past its intended closing quote and absorb whatever followed it, while the
> value as a whole still matched the "valid annotation" shape.
> This means a crafted {{javaAnnotation}} value such as:
> {code:java}
> java.lang.SuppressWarnings("x") static { System.exit(1); }
> @java.lang.SuppressWarnings("y")
> {code}
> passes validation and is emitted verbatim into the generated class —
> injecting arbitrary declarations and a static initializer that runs when the
> class is loaded.
> h3. Impact
> Anyone who can influence a schema's {{javaAnnotation}} property can inject
> arbitrary Java into the generated (and subsequently compiled) sources.
> h3. Fix
> Tighten the string-literal grammar so its body may only contain recognized
> escape sequences ({{\\ \" \n \t \f \b}}) or characters that are not a quote,
> backslash, or line terminator. An unescaped quote now correctly ends the
> literal, so injected trailing tokens no longer match and the value is
> rejected. Line terminators (CR, LF, NEL, LS, PS) are also excluded so a value
> cannot spill onto extra lines. Legitimate annotations
> ({{SuppressWarnings("unchecked")}}, {{Deprecated(forRemoval = true, since =
> "forever")}}, and values with escaped quotes) continue to validate. A
> regression test is added.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
