CVE-2020-1945 in gwt-dev's ant dependency

[melo0187]

GWT version:2.8.2
Browser (with version): N/A (compile time issue)
Operating System: any OS affected as far as I understand

---

Description

gwt-dev:2.8.2 relies on ant:1.6.5, which is affected by CVE-2020-1945.

Apache Ant 1.1 to 1.9.14 and 1.10.0 to 1.10.7 uses the default temporary directory identified by the Java system property java.io.tmpdir for several tasks and may thus leak sensitive information. The fixcrlf and replaceregexp tasks also copy files from the temporary directory back into the build tree allowing an attacker to inject modified source files into the build process.

We are using gwt-maven-plugin for our builds and as far as I understand this relies on gwt-dev for compilation. This is why I assume we are affected by this vulnerability.
Especially when building with a public cloud provider the attack is critical.

Are there any plans to update the ant dependency in gwt-dev to mitigate this CVE?

Steps to reproduce

Found by owasp dependency-check:
mvn dependency-check:check

Known workarounds

None. GWT version 2.9.0 still references ant:1.6.5.

Links to further discussions

https://nvd.nist.gov/vuln/detail/CVE-2020-1945

[niloc132]

You should never deploy gwt-dev as part of your application, unless you are doing something like re-running the GWT Compiler on your running app server, so this should be a non-issue for most deployments. are you running ant as part of your running server?

With that said, it appears that the mitigation section of RAT-269 should apply here as a workaround:

Mitigation:

Ant users of versions 1.1 to 1.9.14 and 1.10.0 to 1.10.7 should set the
java.io.tmpdir system property to point to a directory only readable and
writable by the current user prior to running Ant.

[melo0187]

Thank you for the quick reply!

I'm sure we never deploy gwt-dev as part of our application and thus don't run ant in our running server.

However now I'm unsure whether I misunderstood your point or the CVE.
As far as I understood the gwt-maven-plugin depends on gwt-dev and thus transitively on ant to compile the code during our build step. If this build step happens on an untrusted system like in a public cloud setup, the possibility for an attacker to inject modified source files into the build process seems especially critical.
So not deploying gwt-dev with our application is not eliminating this risk or am I missing something?

Thank you for pointing out the workaround. I will investigate how we might apply this to our situation.

[jnehlmeier]

gwt-dev uses a single class ZipScanner from ANT to find resources within jars in exactly the same way as ANT would do it. Otherwise ANT is not used during the build.

Maybe that file should be copied and repackaged into the GWT distribution in the future so that gwt-dev does not depend on whole ANT library anymore.

[niloc132]

My reply was meant to help you mitigate this issue in your own env right away, not to brush this off as unimportant.

If your risk model is "we might build to a machine where other users can write to its tmp dirs" then yes, this definitely needs to be addressed promptly, or the workaround I mentioned explored. That said, I believe that even cloud build providers do not let filesystem changes leak from one organization (or even build) to another, so this particular attack seems unlikely? If you are running somewhere like a shared tomcat instance where other users can deploy arbitrary wars or log in and poke the filesystem, then yes, that would definitely be a concern. I'm not quite sure where the line is between these.

[melo0187]

My reply was meant to help you mitigate this issue in your own env right away, not to brush this off as unimportant.

And I did not understand it that way. I'm very glad to get your feedback on this topic!
Luckily we had no need to hurry, because we are just migrating our CI/CD to the cloud and are currently still building our application on our own physical infrastructure. I just wanted to make sure we take this into account for our migration to the cloud CI/CD infrastructure.

gwt-dev uses a single class ZipScanner from ANT to find resources within jars in exactly the same way as ANT would do it. Otherwise ANT is not used during the build.

This is good to know, thank you! I believe this is good news. The CVE states:

The fixcrlf and replaceregexp tasks also copy files from the temporary directory back into the build

If gwt-dev does not make use of these tasks at all, than I don't see how this aspect of the CVE would apply to gwt-dev.

[niloc132]

Thanks for your follow up. I agree that we are probably unaffected, but it would certainly help if we could ensure that by limiting our exposure.

I'm trying to update a few other components within the compiler right now, will tackle this one next.

[niloc132]

https://gwt-review.googlesource.com/c/gwt/+/22600

[niloc132]

The fix for this is merged, we now use a minimal ant jar so that only zips can be read.