Malware
From APIDesign
At the end of May 2020 the GitHub guys announced a Malware attacking developer machines via NetBeans Ant based projects. See The Octopus open source supply chain article.
Contents |
Don't Blame the Editor!
I have to admit I am not sure I should be ashamed or happy? Helping spreading viruses isn't really something one should be proud of, but at the end NetBeans IDE itself is quite innocent here. The attack doesn't use the NetBeans code itself, it just modifies the Ant build files written down by the IDE. It knows the layout of the files, it knows their structure and knows what to modify to spread itself. Blaming NetBeans for that is just like blaming your Makefile editor for saving files that get later modified and do a harm to your computer. The problem isn't the IDE nor the editor, the problem is that the developer has allowed an untrusted code to run on own computer and modify local executable files.
Popularity is Popularity
On the other hand, I haven't noticed such amount of buzz about NetBeans for a long time. Even negative popularity is a popularity and I enjoy reading description of the virus attack against the Ant build files written down by NetBeans from independent researchers! Moreover, as the researchers noted, It was interesting that this malware attacked the NetBeans build process specifically since it is not the most common Java IDE in use today. True, NetBeans is no longer hot and it is fair to ask why did the attackers choose NetBeans? My favorite explanation is that it was a targeted attack - an attack against somebody who was known to use NetBeans to develop some application using Ant based projects generated by NetBeans. Might it be a student's prank against roommates? Might it be more serious?
In any case it is clear, the malware developers could easily use the same attack vector against Make, Gradle and even Maven. The chances to spread the virus would be even higher given the dominance of these build systems over Ant. All that is needed is to locate sources of Makefile, build.gradle and pom.xml and mangle them a bit to execute malicious code. In addition to that one can modify the locally cached JAR files in $HOME/.m2/repository directory & co. just like the octopus malware did for the Ant based projects.
Vulnerable Build Systems
The current build systems pay little attention to security. Everyone shall be aware that by running a build one is executing a potentially untrusted code. The build systems themselves provide no isolation by itself, the best one can do is to create a virtually isolated environment to perform the build from scratch and throw the results away after that. However, the situation may be even tougher, certain build systems (and their IDE integration) may trigger the untrusted code even when you are inspecting the code - e.g. even without starting the build. I have described this flaw in my article where I claimed that Gradle belongs to the Ant age! - in order to assemble a classpath (a prerequisite to editing Java sources) the IDE has to execute build.gradle which can do anything! When I wrote the article Gradle guys couldn't understand why having a Turing complete build system is wrong. But I assume they get it one day...
Maven & Apache NetBeans 12
Let's download just (about to be) released Apache NetBeans 12 to the rescue! First an foremost NetBeans 12 supports Maven based projects out of the box - e.g. when you create new project, it is no longer Ant based, but Maven based. NetBeans still recognizes the Ant based projects, as well as Gradle based projects, but because of the declarative format of Maven and the ability of NetBeans to deduce classpath & co. without executing a single line of Maven code, we have decided to standardize around Maven. Developers still have to be careful when executing their Maven builds, but should an attack against that appear in the future, there is not going to be anything NetBeans specific in it.
Download Apache NetBeans 12 - the best UI for Maven ever seen!
Follow
