Malware
From APIDesign
(→Popularity is Popularity) |
(→Popularity is Popularity) |
||
| Line 7: | Line 7: | ||
=== Popularity is Popularity === | === 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 | + | 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 researches 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 serious application using [[Ant]] based projects generated by [[NetBeans]]. |
Because, 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. | Because, 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. | ||
Revision as of 07:03, 1 June 2020
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 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 researches 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 serious application using Ant based projects generated by NetBeans.
Because, 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!
Follow
