Proposal to change default annotation processing policy in JDK 23
1–10 of 108 posts
Re: Proposal to change default annotation processing policy in JDK 23
#2I assume this is to prevent a file-dropping attack, similar to DLL injection.
How hard is this to exploit in practice? Does javac include the current directory in the class path? Does it look in other directories that are easy for other users to drop files in?
Also, how much are people running javac directly? I would guess a lot of people use build tools like Gradle or Ant that limit the class path, right?
Re: Proposal to change default annotation processing policy in JDK 23
#3I assume this is to prevent a file-dropping attack, similar to DLL injection. How hard is this to exploit in practice? Does javac include the current directory in the class path? Does it look in other directories that are easy for other users to drop files in? Also, how much are people running javac directly? I would guess a lot of people use build tools like Gradle or Ant that limit the class path, right?
Using Gradle, ant or Maven still means, in the end, you’re calling javac. All it takes for this to be exploited is for the files to be dropped anywhere in the classpath.
Re: Proposal to change default annotation processing policy in JDK 23
#4I assume this is to prevent a file-dropping attack, similar to DLL injection. How hard is this to exploit in practice? Does javac include the current directory in the class path? Does it look in other directories that are easy for other users to drop files in? Also, how much are people running javac directly? I would guess a lot of people use build tools like Gradle or Ant that limit the class path, right?
Not sure how much that would help. As far as I understand if you have access to putting stuff in the class path surely you can just override Java classes and run arbitrary code that way.
Re: Proposal to change default annotation processing policy in JDK 23
#5I assume this is to prevent a file-dropping attack, similar to DLL injection. How hard is this to exploit in practice? Does javac include the current directory in the class path? Does it look in other directories that are easy for other users to drop files in? Also, how much are people running javac directly? I would guess a lot of people use build tools like Gradle or Ant that limit the class path, right?
How hard is this to exploit in practice? Very - this is a silly update in OpenJDK's war against things like Project Lombok.
It _seems_ easy to exploit: Just.. get any jar file containing an annotation processor on the classpath and it will be executed as part of `javac` - and almost every java build tool calls javac under the hood.
However, this is misleading: _if_ somebody with malicious intent manages to either sneak a jar file into the build dependencies somehow, or manages to libxz-style take control of a commonly used dependency, the damage is done. That jar will also be on the classpath when running the app. So now we're running compromised code. Java is not a sandboxed thing, running malicious code inside a JVM is a bit like an XSS web attack: The game is lost. Totally and utterly.
The fact that javac runs annotation processors by default until JDK23 does mean that a compromised build chain now runs _during the build_, whereas starting with JDK23 they'll only run when you run the app.
This doesn't seem impactful to me; I'm having a hard time figuring out scenarios where this is meaningfully less bad. Developers tend to run the app they are writing. The odds a developer will build a source tree and never actually run what they built, seems insufficient to consider this a meaningful contribution to security.
CI servers might be a useful place to look for 'systems that will run the build but will not run the app', except - no. Just about every CI tool will run some tests, thus, running the app, thus, running the malicious code.
Which gets us back to: OpenJDK's backwards-compatibility breaking crusade. The OpenJDK team has also broken reflection (you can no longer access anything in another module that wasn't explicitly exported without command line switches, even though reflection used to be able to do this. Reflection has 'CARE! You are accessing APis that were not designed to be messed with!' written on the tin. It's.. the point of it). - same reasoning. "For security" without being particularly clear about how that update contributes to security. It's not about 'it is impossible to use reflection to cause serious damage' (it is very possible to do that, in fact). It's more about: .... if you are running malicious code inside a JVM, we've got much, much bigger problems.
It's sort of like stating that security is improved by ensuring that it is no longer possible to open the front door from inside the house without a key. Seems nice - but, they're... already inside the house.
Re: Proposal to change default annotation processing policy in JDK 23
#6I assume this is to prevent a file-dropping attack, similar to DLL injection. How hard is this to exploit in practice? Does javac include the current directory in the class path? Does it look in other directories that are easy for other users to drop files in? Also, how much are people running javac directly? I would guess a lot of people use build tools like Gradle or Ant that limit the class path, right?
Not sure how much that would help. As far as I understand if you have access to putting stuff in the class path surely you can just override Java classes and run arbitrary code that way.
I think the difference is that annotation processors run arbitrary code at compile time.
An org might have e.g. a CI with a build environment that’s not as well-sandboxed as the test environment for the built app, because a Java compiler isn’t generally expected to (and other than through annotations, usually doesn’t) expose arbitrary code execution abilities to the payload of code being compiled.
Re: Proposal to change default annotation processing policy in JDK 23
#7I assume this is to prevent a file-dropping attack, similar to DLL injection. How hard is this to exploit in practice? Does javac include the current directory in the class path? Does it look in other directories that are easy for other users to drop files in? Also, how much are people running javac directly? I would guess a lot of people use build tools like Gradle or Ant that limit the class path, right?
How hard is this to exploit in practice? Very - this is a silly update in OpenJDK's war against things like Project Lombok. It _seems_ easy to exploit: Just.. get any jar file containing an annotation processor on the classpath and it will be executed as part of `javac` - and almost every java build tool calls javac under the hood. However, this is misleading: _if_ somebody with malicious intent manages to either sne…
> That jar will also be on the classpath when running the app.
No. In many maven config, runtime classpath is not the same as compile time
Re: Proposal to change default annotation processing policy in JDK 23
#8Earlier quoted context omitted.
Not sure how much that would help. As far as I understand if you have access to putting stuff in the class path surely you can just override Java classes and run arbitrary code that way.
I think the difference is that annotation processors run arbitrary code at compile time . An org might have e.g. a CI with a build environment that’s not as well-sandboxed as the test environment for the built app, because a Java compiler isn’t generally expected to (and other than through annotations, usually doesn’t) expose arbitrary code execution abilities to the payload of code being compiled.
Is it actually common practice these days to have Java repositories that do not contain the build scripts, packaging, etc?
The last time I looked at maven, it seemed easy enough to have it run arbitrary code directly during the build.
Re: Proposal to change default annotation processing policy in JDK 23
#9I assume this is to prevent a file-dropping attack, similar to DLL injection. How hard is this to exploit in practice? Does javac include the current directory in the class path? Does it look in other directories that are easy for other users to drop files in? Also, how much are people running javac directly? I would guess a lot of people use build tools like Gradle or Ant that limit the class path, right?
How hard is this to exploit in practice? Very - this is a silly update in OpenJDK's war against things like Project Lombok. It _seems_ easy to exploit: Just.. get any jar file containing an annotation processor on the classpath and it will be executed as part of `javac` - and almost every java build tool calls javac under the hood. However, this is misleading: _if_ somebody with malicious intent manages to either sne…
Annotation processors on the compile classpath are not automatically added to the build output's runtime classpath. The status quo doesn't change, because annotation processors also don't do anything when running the app (e.g. with java and not javac), on any Java version.
Re: Proposal to change default annotation processing policy in JDK 23
#10I assume this is to prevent a file-dropping attack, similar to DLL injection. How hard is this to exploit in practice? Does javac include the current directory in the class path? Does it look in other directories that are easy for other users to drop files in? Also, how much are people running javac directly? I would guess a lot of people use build tools like Gradle or Ant that limit the class path, right?
How hard is this to exploit in practice? Very - this is a silly update in OpenJDK's war against things like Project Lombok. It _seems_ easy to exploit: Just.. get any jar file containing an annotation processor on the classpath and it will be executed as part of `javac` - and almost every java build tool calls javac under the hood. However, this is misleading: _if_ somebody with malicious intent manages to either sne…
> OpenJDK's backwards-compatibility breaking crusade. The OpenJDK team has also broken reflection (you can no longer access anything in another module that wasn't explicitly exported
I’ve been out of the Java world recently, but my understanding is that an application developer can still do anything they want. All of these new restrictions are for library developers. To be clear the library developer can still do anything, they just have to make it explicit.
This is the opposite of a backwards compatibility breaking crusade. This is a crusade to make sure application developers don’t accidentally depend on libraries that are either breaking encapsulation or depending on JDK internals. This should improve backwards compatibility.