Singing Mods / Fingerprint System

[Cuchaz]

Hello,

 

Can anyone explain how the fingerprint/signature system works for mods?

 

A friend tried to explain it to me, but from what I understand, the implementation seems very insecure. I probably don't understand it correctly. I searched, but I couldn't find any documentation on how this system works either.

 

It seems like the mod jar gets signed and the signature gets added to the @Mod annotation, which is somehow interpreted and compiled into the class file through the magic of Java annotations. Then, when the mod jar is loaded by Forge, if the signature is invalid, Forge sends an event to the mod, and the mod decides for itself how to handle the invalid signature state.

 

If that's correct, then what's to stop an attacker (who's say, trying to insert a trojan into my mod) from just deleting the invalid signature event handler and the signature check value from the jar entirely?

 

Thanks,

Cuchaz

[hydroflame]

it could seem stupid, but can you link as ive googled "minecraft signing/fingerprint mod" and nothing came out :\, maybe im just retarded

 

feel free to use the  LMGTFY if i was just retarded

[Cuchaz]

What it is it you want me to link? If it's documentation for the signature system in Forge, I don't know where to find it either.

 

Cuchaz

[hydroflame]

ooooooooohhhhhhhhhh, i tought it was a mod seperate from forge, like IC2, EE2, buildcraft etc

[Cuchaz]

The only documentation I can find on it is the javadoc here:

http://jd.minecraftforge.net/cpw/mods/fml/common/Mod.html

 

public abstract String certificateFingerprint

 

Specifying this field allows for a mod to expect a signed jar with a fingerprint matching this value. The fingerprint should be SHA-1 encoded, lowercase with ':' removed. An empty value indicates that the mod is not expecting to be signed. Any incorrectness of the fingerprint, be it missing or wrong, will result in the FMLFingerprintViolationEvent event firing prior to any other event on the mod.

[hydroflame]

hmmm, well sha1 is actually pretty solid. and from only this piece of information i cant seem to think of any huge security break ...... considering were talking about minecraft not your credit card number/personal information....

[Cuchaz]

I agree, in part. Forging a signature is probably not within the capabilities of your average (or even gifted) Minecraft hacker. However, we are talking about protecting credit card information here. If someone subverts my mod and inserts a keylogger/trojan, they could possibly steal someone's banking credentials.

 

The security weakness I see in this case is not in SHA-1. It's in how mods with invalid signatures are handled by Forge. It seems that Forge asks the mod (that has failed a signature check and therefore should be untrusted) what to do about the invalid signature.

 

Cuchaz

[hydroflame]

right, but the thing is people have to know where they should know that they shouldn't get their mod from www.trolololhackerwarez.com and honestly since its java, any hacker could tottally re-sign the package. It's not hard. Best thing to do is distribute your mod from secure/valid locations and add a note or readme that says they shouldn't be getting it from anywhere else.

 

 

[hydroflame]

i mean, saying forge isnt secure because of this is the same saying windows isnt secure because people are able to voluntarely install virus on their computer by downloading from bad locations... like yes it is an issue, but ..... theres not much we can/will do about it.

[Cuchaz]

Any time you build a system that is designed to execute arbitrary code from the internet with an interactive user's credentials, you're not allowed to blame all your security problems on the operating system.

 

Also, signing java jars with my private key is actually seriously hard to do if you don't have my private key. That's the whole point of cryptography. If you think you can forge my signature, I'd love to see you try.

 

I've already asked my users to only download my mods from trusted sources. But I have no control over who redistributes my jars and who downloads the distributed versions. If, by your own admission, this signature system can't reject malicious modifications, what purpose does it serve?

 

Anyway, would it be possible to get a developer's opinion on this? I'd love to talk to the person who wrote it to learn his/her thinking.

 

Cuchaz

[hydroflame]

Also, signing java jars with my private key is actually seriously hard to do if you don't have my private key. That's the whole point of cryptography. If you think you can forge my signature, I'd love to see you try.

 

they could sign it with another key. obviously the private/public key system is super secure, but i could technicly make another jar and sign it with another key, insert that key in the mod as well and tada the whole thing is screwed.

 

of course this signed jar could not log into YOUR server because you are signed with the original key but they could easily sign into other server with the same key and or single player.

 

Any time you build a system that is designed to execute arbitrary code from the internet with an interactive user's credentials, you're not allowed to blame all your security problems on the operating system.

jeez I'm not blaming the OS I'm just saying if people are not paying attention they will get caught. i think part of the responsibility is to the developper's and another part to the users.

 

this signature system can't reject malicious modifications

if thats not already done in forge, you could check that every player that logs in still have the original source/fingerprint of the mod and reject does that don't.

 

[Cuchaz]

If signing the jar with another key will pass the security check, then that further illustrates the ineffectiveness of the system. If anyone is allowed to sign the jar, then the signatures are pretty meaningless.

 

My mod is a client and a server mod. So if the server mod was downloaded from the same infected source as the client mod, then server-side-only checks are also useless. That also ignores the fact that a user doesn't need to log into a server for an infected client mod to wreak it's havok on the user's computer. But at least we're thinking about how to fix the problem now. I think in order to make this system work correctly, we'd need to make some changes to Forge itself.

 

Typically, signature systems are based on some idea of trust. Someone trusted keeps a list of trusted public keys. Then new code is considered untrusted until it can be verified that the code was signed with the private counterpart to a trusted public key. Trusted code is allowed to execute. Untrusted code is not allowed to execute.

 

Now, that system exactly as described probably wouldn't work for Forge unless you want everyone to sign their code and keep a copy of every possible mod author's public key. To avoid that kind of hassle, I'd suggest making an of opt in system. For mod authors that want the security of an actually-functioning signature system, they could opt in to this list.

 

Alternatively, other systems deal with executing untrusted code by using a sandbox. That's probably too much trouble to implement though in this environment unless you can find a nice seamless Java library.

 

But the worst possible thing you can do is implement a non-functioning security system and advertise that it actually works. This only gives people a false sense of security and can actually cause more harm than good.

[hydroflame]

If signing the jar with another key will pass the security check, then that further illustrates the ineffectiveness of the system. If anyone is allowed to sign the jar, then the signatures are pretty meaningless.

if i look at this class

cpw.mods.fml.common.asm.FMLSanityChecker 

it seems that the keys are hardcoded in (maybe im wrong)

so decompiling a mod, changing the key and recompiling, signing with the same key would unfortunately NOT be hard

 

But the worst possible thing you can do is implement a non-functioning security system and advertise that it actually works. This only gives people a false sense of security and can actually cause more harm than good.

 

im not sure either this is intended to me or not :\

 

 

For mod authors that want the security of an actually-functioning signature system, they could opt in to this list.

i would actually opt in for that and im even offering to host the server that would authenticate if you are serious about this

[Cuchaz]

If there are private keys baked into FML, we should fix that first thing. The only keys that should see the light of day are public keys. Private keys should be kept in the deepest darkest hole possible.

 

Sorry, I didn't mean "you" individually. I meant the unspecified "you." I'm sure we can improve on whatever security system is currently built into Forge.

 

If we actually want to do that, we don't need to host any authentication servers. We just need to write a little code for FML (which I'll offer to do if you want) and maintain the opt in list of public keys for mod authors. The list probably needs to be distributed with Forge. We'll have to decide on encryption/digest/signature standards and such as well.

 

Cuchaz

[hydroflame]

If there are private keys baked into FML, we should fix that first thing.

that was actually derp of me, its clearly NOT the private keys... *wtf was i thinking, must be the beers*

 

but about that authentication server the thing is if we distribute the list with the forge theres 2 possibility, either we can only update our mods at the same time forge does, or we would need to update a freacking list every single time anybody updates his mod/amkes a new mod... auth server might be actually more efficient as we could make it so that the list is always up to date and the client wouldnt need to download a new list (comparing to the 2nd case)

[Cuchaz]

Nah, none of that's really necessary. All we need to do is keep a list of trusted modders (who opt into this list), their public keys, and their mods. As long as they sign all their updated jars with the same private key, we don't need to update the list of public keys every time a jar is updated. We only need to update the list when a new mod author wants to opt in or when a mod author releases a new mod.

 

Now, if redistributing the list every time a new mod author opts in or releases a mod is still too frequent, then we can start thinking about ways to get the FML to automatically download updates of the list. For that, we would just need an HTTP server. If you want to host that, awesome!

 

Cuchaz

[hydroflame]

we don't need to update the list of public keys every time a jar is updated

yeah right, i forgot theres a thing in forge that kicks people with outdated version of the mod from server. but i kinda forgot that the signature and version can be different

 

 

the other thing is, i dont think forge devs are really interrested in keeping that list updated (specially with the numbers of request they will get, people providing mods that aren't even completed and all). also, doesnt that mean that whoever is in charge of this will ahve to read through all the code to see if the developpers are "safe" ? because if someone for instance doesnt put his mod on the list, another person comes in and places malware in his mod and signs the jar then submit the mod on the list, that would bypass the whole system (maybe im just exagerating there)

 

 

[Cuchaz]

That's a great question.

 

If you want this list to be a list of Modders Who Probably Wont Hack You, that's a lot of work for the Forge team. It's definitely not worth the effort to vet every piece of mod code.

 

But all the list really needs to be is a list of Modders Who Are Allowed To Write Code for Mod X.

 

That completely moves the burden of "Which modders do I trust" onto the end user. Then Forge can just worry about, "Did this code really come from modder Y?"

 

In the second case, the list would never need moderation as long as we only add entries to the list. Now, if someone wants to change an existing entry, that would need some kind of approval I think. But that should rarely happen, and if you wanted to, you could completely disallow changes to existing entries by policy.

 

Cuchaz

 

[hydroflame]

this post should be moved to the suggestion board

[Cuchaz]

It wasn't originally a suggestion, but sure. Moderate away.

[LexManos]

Any time you build a system that is designed to execute arbitrary code from the internet with an interactive user's credentials, you're not allowed to blame all your security problems on the operating system.

We arn't writing something that is designed to execute arbitrary code from the internet.

We're writing something thats designed to execute arbitrary code from the local disk.

Major difference. Mainly being the fact that we do not place anything on the disk and it is SOLEY the user's responsibility what gets put there.

The OS analogy works, You don't blame windows when you download and run a file called 'FreePorn.exe' you blame the user, for being stupid.

If the files are on disk, then we must assume that the damage is done and not give two shits.

 

Now, if say, Windows update were to download and install a virus during it's nightly update. THEN you blame Microsoft.

But as FML/Forge has no such system, it's not on us.

 

If signing the jar with another key will pass the security check, then that further illustrates the ineffectiveness of the system. If anyone is allowed to sign the jar, then the signatures are pretty meaningless.

Anyone can sign a jar, but if there signature doesn't match the one in-code then it's rejected and as such triggers the violation event.

This event is done before any of the mod code is done. The event is fired in mods that are already loaded.

 

Anyways before you guys go all crazy about this.

We will NOT be hosting a central trust server/list.

We will NOT be forcing all modders to sign there code.

We will NOT do anything more then we are already doing.

 

This is NOT designed to be fort knox.

Anyone who installs a mod onto there computer takes SOLE RESPONSIBILITY.

 

Signatures in java are a joke. They should not be used for ANY form of security. And they are NOT used as security in FML. They are used as sanity checks. It is designed so that a Modder can check his own, or other's signatures and verify that he is running his own, un-tampered code.

[hydroflame]

thats okay, people who really want more security can always do things without requiring a new forge feature.

i had a feeling that this was actually a big thing and i know you guys already have a lot on your hands.

 

[Cuchaz]

It is designed so that a Modder can check his own, or other's signatures and verify that he is running his own, un-tampered code.

 

The point I'm trying to make is that the system can't meet this guarantee. The system is broken. It doesn't work. From reading how the system works, it seems quite trivial to hack one of these "signed" jars. And the mod author can't do anything to keep someone from running the hacked code.

 

I'll explain why.

 

Anyone can sign a jar, but if there signature doesn't match the one in-code then it's rejected and as such triggers the violation event.

 

You're relying on the mod jar (which should not be trusted) for two things. 1: the correct value of the jar digest (ie the signature). and 2: what to do when a violation even occurs.

 

Because of the way the system is implemented, there's no way for me as a mod author to prevent hacked versions of my mod from being loaded and running arbitrary code. The tamper-evident part of the system doesn't even work correctly.

 

All an attacker needs to do to subvert a mod is delete 1 and 2 from the jar, and all the "security" is completely disabled. If the attacker wants to be fancy, the attacker could re-sign the jar and overwrite 1 without even needing to change 2.

 

Signatures can be an extremely secure system. You just have to understand how crypto systems work and then implement them properly.

 

Also, try to be nice. I'm not just complaining. I'm offering to help you fix it.

[LexManos]

Again you're thinking that this is intended as security it is not.

Forge/FML are not a security firm, we do not have the authority to designate who is secure and who is not.

The end user decideds who he is going to trust by downloading and installing there mod.

This has NOTHING to do with us.

 

The point I'm trying to make is that the system can't meet this guarantee. The system is broken. It doesn't work. From reading how the system works, it seems quite trivial to hack one of these "signed" jars. And the mod author can't do anything to keep someone from running the hacked code.

No, the mod author can't do anything from running the 'hacked' code, just like a random mod author can't do anything to prevent you from running your mod.

A mod author CAN however handle the violation event as see that 'My god RandomMod17 says it should be signed but its signature doesnt checkout, I will not run in this untrusted environment'

If every mod does that. Then the 'hacker' {God I hate using that term as that gives them to much credit} would have to modify each mod individually to remove the cross checks.

 

You're relying on the mod jar (which should not be trusted) for two things. 1: the correct value of the jar digest (ie the signature). and 2: what to do when a violation even occurs.

1) That'd provided by the JVM.

2) We have to trust the mod. There is no sane way for us to tell the difference between a mod with no signature and a 'hacked' mod.

 

Anyways, we are providing the same level of 'security' that the JVM provides. Actually we are providing a bit more. By allowing a simple system of cross checking and redundancy.

 

Again, FML/Forge signatures are not for security. Any security when it comes to things like this is a farce and shouldn't be trusted.

 

Also, try to be nice. I'm not just complaining. I'm offering to help you fix it.

You're offering to fix something that isn't broken. And are trying to extend our domain/liability WAY beyond what we should do.

 

However, if you as a third party wish to do something completely unrelated to Forge. And write a utility mod that tries to govern all of this, then that is on you and we don't care.

[Cuchaz]

You touted your signature system as a way for mod authors to tell if their mod has been tampered with. Whether or not you want to call it a "security" system is irrelevant. I asserted that it doesn't work and disclosed the exploit. You haven't yet convinced me that it actually does work.

 

It's clear to me now that you have no interest in fixing the flaw in your tamper evident system. I'm pretty sure you don't even understand what's wrong with it. Statements like "we have to trust the mod" lead me to believe that I'll never be able to convince that something is actually very very wrong.

 

That's fine. I'll spend my attention elsewhere.