[
https://issues.apache.org/jira/browse/AVRO-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18101444#comment-18101444
]
ASF subversion and git services commented on AVRO-4313:
-------------------------------------------------------
Commit beb766255fc4028b31f3706cc5ccf21e20c2d7c0 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=beb766255f ]
AVRO-4313: [java] Clarify javaAnnotation validation comments (#3907)
Rewrite the comments around the annotation-validation grammar and its
regression test in plainer language. Explain why the check exists (the
javaAnnotation property is emitted verbatim into generated source) and
what an unescaped quote in a string literal would allow, so the intent is
clear to readers who are not familiar with the regex.
Comment-only change; no behavior change.
> [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)
