Currently there is no way in Bukkit (not sure about ) to verify the origin of a plugin, websites like 9minecraft use this to spread malicious (and pirated) plugins and you can’t do much (maybe browse for a website you ‘trust’ and look for an md5sum, but who knows how to check such a thing?) to detect this.
I propose to check the signatures of each plugins before it is loaded and at least display on server start if and by whom the plugin was signed. This can also be used to pin the dev of a plugin similar to how ssh fingerprints work. Sponge could save fingerprints of the certificate when the plugin is first loaded and then check next time if the certificate fingerprint for the plugin suddenly changed as this would suggest that the origin of the plugin changed (pirated and malicious?). Also one could detect if the plugin was tempered with or the file corrupted.
I am not talking about enforcing signed plugins or forcing any dev to use a certificate, for this to work simple self signed certificates would already help. In the meantime it would allow devs that own valid certificates to use them.
Pro signing:
allows checking of plugin origin
easy check of plugins integrity i.e. was it tempered with?
could also be used to sign ‘approved’ plugins (a jar can have multiple signatures, e.g. one from the dev, one from BukkitDev, …) where a server admin could decide to enforce certain signatures (opens potential for sane auto-updater plugins)
a tool for admins to check the integrity of their pluginset
a dev can easily post his public key on his website
Contra:
devs should sign their plugins
In order to get an idea how complex simple signature checking is, I wen’t ahead and wrote a little Proof of Concept for jar signature verification, I call it ‘Javer’. It can verify signatures on arbitrary jars made via the jarsigner tool (built-in java tool) and displays the certificates used.
Not interested?
If you think viruses are not a problem in Bukkit (same idea should work for forge mods too) I present you this PoC (contains intended bugs as a copy paste prevention). It infects all other plugins it may find, which could be easily detected with signing.
Yes, they are a good start, they approach one use case for signed mods, I’m more interested how to provide them with tools to do so. Although I’m more concerned about server side mods/plugins for now.
I would imagine that a server side virus could cause client side damage, and vica-versa. Signing would benefit both.
I think that if sponge provides the tools that it should be required for any plugin to run on the server that it be signed, or at least have a dummy setting to allow it, a setting that defaults to not even being included in the settings file but must be added manually to allow unsigned plugins.
There’s an easy fix for this: Only download the plugins from Sponge’s plugin repo or the original developer’s CI. I think signing the plugins would make the process just more complicated
but this leaves auto-updater and the like defenseless, admins don’t like to browse to the repos each time and check if the md5sum is still correct. How do you detect that a plugin wasn’t tempered with otherwise?
Server owners need to do their homework. If they cannot take a moment to determine whether or not the plugins they are downloading are from legit websites then they shouldn’t be running a server in the first place.
Signing the plugin and adding levels of complexity doesn’t help the source of the problem.
Jar signing should be used no matter what. For my business I have both my own personal comodo cert for signing my jars, and I always recommend to any clients that want me to release android apps under their domain that they should buy a cert also. It adds an extra level of trust and authenticity if you are using a professionally issued code signing cert.
Granted, I realize this isn’t feasible for most people as they run $180/year for a single cert. However, a website that would allow developers to upload a signed jar, analyze the signature, and then apply it to their account so it will show any file that they upload is authentic would be quite nice. Even if it is just a self issued cert.
Huh, that would probably be why I said that I realize it isn’t feasible for most people and I didn’t suggest that it be adopted wholesale across the board.
Have you seen how easy checking signatures is? and how easy it is to use self signed certs?
Verification is around 50 lines of code in vanilla java, signing is one line in terminal. There is even a jarsigner plugin for maven. This is in no way ‘complex’.
Given how we’re loading plugins currently, it’s fairly likely the FML log file will do the same thing as with mods – print out the key signature of signed jars or a message saying it’s unsigned in the log.
We really shouldn’t be doing any bigger verification than that, since it’s pretty trivial to re-sign a jar after changes and we don’t want to require all developers to get special keys.
you can create a key with a one liner in terminal: keytool -genkey -alias mykey -keyalg RSA -keysize 1024 -validity 365 -keypass privatepassword -keystore identity.jks -storepass password
How do you know if it changed? Whoever edited it can just as easily delete the cache with old signatures, and without any other source you have to assume the current key is correct.
That’s not a ‘special key’, just a normal self-signed one which doesn’t say anything except “Hey someone knows how to use jarsigner.” With a self-signed key you have to rely on external sources to tell you which key is ‘correct’ because it’s trivial to replace with a different self-signed key.
As a note, I would actually recommend sponge set up a certificate authority with the root cert being embedded in sponge so that devs can apply for and receive a signed cert, ideally where sponge would also verify the username on sponge dev with the developer name in the plugin’s metadata.
My two cents on this is that if we’re adapting a bukkitdev-esque plugin hosting system here at Sponge, wouldn’t jar file md5 hash matching be enough to verify the legitimacy of a plugin?
Server owners could have the option to enable/disable non-official plugins that they could have made by themselves or downloaded from a non-official website. If they enable that option, that’s their fault.
I know I could be over-complicating this a bit, but that’s just what I thought of when looking at this thread.
md5’s are great for verifying if a plugin was corrupted (unintentionally), but it is not a means to authenticate a plugin or it’s origin. It is much harder to have some public repo with all the up to dates md5s of all versions of ‘approved’ plugins than just check plugins if they are signed with the correct key. (Not to mention that md5 is no longer considered cryptographically secure.)
At most, we could host a public certificate repository.
However, the question becomes:
Given mod X, how do we know it’s supposed to be signed by certificate Y? They could just rename the identifier for the mod but does that mean you need to reject all unsigned mods then?
