Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proposal to change default annotation processing policy in JDK 23

mail.openjdk.org

Post reply on HN
Print view View original

11–20 of 108 posts

Re: Proposal to change default annotation processing policy in JDK 23

#11

Post by jillesvangurp »

senorrib wrote: post #3
MarkSweep wrote: post #2

I 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.

It's an annotation processor. They generally require annotations in your own source code to kick in.

As a security risk this is pretty minor. About on the same level as any software project with any dependencies risking running arbitrary code unless you audit those dependencies. This is of course a very real risk and it has affected a bunch of projects. But it's not really stopping people from using things like cargo, npm, etc.

Overall, it makes sense to make the use of annotation processors a bit more explicit. With Kotlin this is kind of how it works as well. You have things like ksp that you have to configure explicitly if you want to use them. Additionally there are compiler plugins that you can configure if you need them. It's not a big deal to configure this explicitly. I actually prefer it over magic discovery mechanisms that are hard to debug when they don't work.

So, good change that probably simplifies the build process a little.

Re: Proposal to change default annotation processing policy in JDK 23

#12

Post by vbezhenar »

MarkSweep wrote: post #2

I 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?

I assume this is to have more control over compilation process.

Without annotation processor, you can expect your code to be compiled and behaved in an obvious way.

With annotation processor all bets are off, your code and code that results from compilation are completely different entities.

So with this switch being explicit, you might enforce politics like lack of annotation processors for better clarity.

While security theoretically might be better, in practice with modern build tools there are enough ways to cause code execution, so it probably doesn't matter much.

Re: Proposal to change default annotation processing policy in JDK 23

#13

Post by GauntletWizard »

rzwitserloot wrote: post #5
MarkSweep wrote: post #2

I 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…

This seems a real vulnerability if you're using legacy infrastructure - If you're running your build process on a highly privileged build machine, like a single large Jenkins instance. These machines might have a bunch of subprojects - and a bunch of credentials to login to other prod systems for deployment purposes.

This is not the reason that I prefer containerized build solutions, but it is a real concern, outside of the little bubble that is the startup ecosystem.

Edit: It occurs to me that since I just gave a talk on this, it behooves me to link it: https://youtu.be/dswPHnfGwlY

Re: Proposal to change default annotation processing policy in JDK 23

#14

Post by pjmlp »

rzwitserloot wrote: post #5
MarkSweep wrote: post #2

I 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…

Had some developers not starting to Monkey patch this wouldn't be needed, Java isn't Ruby.

Go is now going to do a similar approach, because internals and not being public symbols apparently isn't clear enough.

Re: Proposal to change default annotation processing policy in JDK 23

#15

Post by kaba0 »

rzwitserloot wrote: post #5
MarkSweep wrote: post #2

I 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…

> this is a silly update in OpenJDK's war against things like Project Lombok

Project Lombok doesn’t use the normal annotation processing system, as that is deliberately “add-only” - you can’t change a class’s implementation, unlike what lombok does. They instead hack into the javac compiler to be able to modify class files, which is a very different mechanism (and prone to break with any javac update, which they don’t control) and I think it’s quite easy to see why it’s not loved (though this “war” bullshit is just propaganda from the creator’s ego or whatever).

Also, default being strict is a good stance (both in case of the reflection restrictions) — you can access everything with just a few command line flags, so I don’t really see all the complaints. The point is, you have to know about whether some module in your system accesses another in a non-standard way. Like, are firewalls overly strict because they only allow traffic through port 22 when specified to do so? Should they start with allow-all?

Re: Proposal to change default annotation processing policy in JDK 23

#16

Post by vips7L »

kaba0 wrote: post #15
rzwitserloot wrote: post #5

Earlier quoted context omitted.

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…

> this is a silly update in OpenJDK's war against things like Project Lombok Project Lombok doesn’t use the normal annotation processing system, as that is deliberately “add-only” - you can’t change a class’s implementation, unlike what lombok does. They instead hack into the javac compiler to be able to modify class files, which is a very different mechanism (and prone to break with any javac update, which they don’…

He knows what Lombok does. He’s the author.

Re: Proposal to change default annotation processing policy in JDK 23

#17

Post by vips7L »

jillesvangurp wrote: post #11
senorrib wrote: post #3

Earlier quoted context omitted.

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.

It's an annotation processor. They generally require annotations in your own source code to kick in. As a security risk this is pretty minor. About on the same level as any software project with any dependencies risking running arbitrary code unless you audit those dependencies. This is of course a very real risk and it has affected a bunch of projects. But it's not really stopping people from using things like cargo…

> They generally require annotations in your own source code to kick in

Right but you don’t know which annotation processor will actually run. Anybody could look for javax.persistence.Entity and do something. There’s no guarantee only your JPA provider will be running and looking at them.

Re: Proposal to change default annotation processing policy in JDK 23

#18

Post by jillesvangurp »

vips7L wrote: post #17
jillesvangurp wrote: post #11

Earlier quoted context omitted.

It's an annotation processor. They generally require annotations in your own source code to kick in. As a security risk this is pretty minor. About on the same level as any software project with any dependencies risking running arbitrary code unless you audit those dependencies. This is of course a very real risk and it has affected a bunch of projects. But it's not really stopping people from using things like cargo…

> They generally require annotations in your own source code to kick in Right but you don’t know which annotation processor will actually run. Anybody could look for javax.persistence.Entity and do something. There’s no guarantee only your JPA provider will be running and looking at them.

In exactly the same way, unless you audit your dependencies, you have no idea what you are going to run. It all boils down to whether you trust your dependencies. The only difference here is that this is a compile time dependency, not a run-time dependency. But unless you checked it, there are no guarantees.

Re: Proposal to change default annotation processing policy in JDK 23

#19

Post by metadat »

rzwitserloot wrote: post #5
MarkSweep wrote: post #2

I 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…

Is the OpenJDK behavior different from Oracle JDK?

Re: Proposal to change default annotation processing policy in JDK 23

#20

Post by martypitt »

rzwitserloot wrote: post #5
MarkSweep wrote: post #2

I 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…

Slightly OT, but sincere thanks from me to you for creating Lombok.

It's a tool that sparks strong opinions, which is a testament to its significance and the impact it has made. You've created something that people are passionate about, whether they're for or against it.

Personally, I'm firmly in Team Lombok. I believe the negative feedback it receives is disproportionate.

For those of us who use it, Lombok significantly improves our coding experience. For those who don't, it's entirely optional and doesn't interfere with their workflow.

Thanks again for creating something that made me enjoy coding in Java :)

Post reply on HN