Launcher/Minecraft Security Exploitation and Fixing

[jakj]

So, I've written a quick little mod that will print to singleplayer chat both the contents of any user-mode--accessible file on the hard drive and the entire list of handles and passwords from lastlogin in plaintext. Now, I am on a crusade to prevent this from happening.

My initial idea was to be able to use Java's built-in Security Manager to restrict access to the technicssp folder, but the problem is that the launcher does not invoke Minecraft as a separate instance of the JVM but loads it within itself. (This appears to be necessary because of the way minecraft.jar+modpack.jar works.)

I tried invoking the launcher .jar with a Security Manager active, and that works, but as I started granting permissions to make it work, I ran into the snag that it needs access to the "user.home" property (which is how it determines the location of .techniclauncher). This is reasonable, but it defeats me.

So, now I'm trying to come up with a Plan C. In theory, if I can find some way to invoke Minecraft directly with a Security Manager active, I can restrict it to read/write only the technicssp folder and nowhere else on the drive. I'm not seeing any way to do this without forking the launcher (probably way too difficult) or manually merging modpack.jar into minecraft.jar (bad) and invoking it by a secondary minilauncher.

Any thoughts?

[hoho]

I won't be of much use for you as I haven't dealt with Java-based security stuff much but I just wanted to clarify that what you try to achieve is preventing mods from doing bad stuff, right?

Might also be a good idea to somehow figure out what server is the client connected to and somehow filter/block all network access to other things or block it completely for SSP.

[jakj]

I won't be of much use for you as I haven't dealt with Java-based security stuff much but I just wanted to clarify that what you try to achieve is preventing mods from doing bad stuff, right?

Might also be a good idea to somehow figure out what server is the client connected to and somehow filter/block all network access to other things or block it completely for SSP.

Yes, I'm trying to prevent mods from doing bad stuff. The password is never passed into the Minecraft instance: Only a session ID; So, if I can somehow invoke a Security Manager between the launcher and the game, it can be put into a nice little secure box. Java by default already has protection against things like out-of-bounds memory access and the like, so (as far as I have reckoned) the only barrier to perfect-security-other-than-JVM-bugs is file access.

I'm not going to touch SMP; It's just too complex. It shouldn't be necessary, anyway, because the password is not sent by the game: Only by the launcher. When you log into a server from within Minecraft, you are authenticated by Mojang's servers to your playing server; You don't authenticate yourself.

[The Merchant of Menace]

Agelian's the one who coded the launcher, so speaking to him seems advisable on this matter.

[jakj]

Agelian's the one who coded the launcher, so speaking to him seems advisable on this matter.

I don't have him in my rolodex. :P

[The Merchant of Menace]

The IRC would be the logical place to begin my good chum :P

[jakj]

The IRC would be the logical place to begin my good chum

Oh, I hadn't even an idea there was one. Good plan.

[The Merchant of Menace]

#technic on SynIRC.

My good chum.

[hoho]

Yes' date=' I'm trying to prevent mods from doing bad stuff.[/quote']Yeah, that's what I thought

The reason I brought in somehow filtering network traffic is to prevent mods from calling "home". Though I guess if you can somehow block them from accessing any data on the disk then they can't really do much more than register that someone is using technic but they have no way of knowing who it is, besides their IP of course.

[jakj]

Yeah, since Java already prevents out-of-bounds memory access, if you prevent the game from accessing any other files except the ones it's supposed to, there aren't any data anyone would care about being transmitted; It becomes a privacy issue rather than a security one, and honestly, that just isn't worth bothering with.

I would honestly laugh if a mod author was so insecure about theirself that they put a usage tracker in their mod. Oh no! Or even always-online DRM! The horror! Oh, won't somebody think of the bees.

[jakj]

Well, I'm rather surprised that nobody else seems worried about this. Is it just overwhelming trust in the modding community at large, or a misguided assumption that "somebody" will always find an exploit before you become a victim to it, or is it just too much work?

It may be the third, actually. I've become frustrated with my attempts at getting a security manager running with the launcher, because I'm just adding permission after permission incessantly, and some of them are even hardcoded directories. There doesn't seem to be any direct and easy way to just tell Java "let it do anything it wants except reading outside its launch directory or subdirectories". Really starting to gain a much greater appreciation for the ease of setting permissions in GNU-based OSes compared to this.

So I'm frustrated. If anybody out there who has a greater knowledge of Java security than do I could help me, that would be amazing. Because otherwise, I just don't see this being feasible, and my hope of increasing Minecraft's security will just fall flat on its face.

[Truculent]

Minecraft security has always been a joke. You can lock it down to the launch directory & subdirectories by jailing the java process itself, but this requires a JRE installation inside the chroot directory, which is rather unworkable for technic launcher. And this wouldn't help anyways -- the lastlogin file is trivially decryptable.

It will be very difficult if not impossible to use the SecurityManager to lock this down, in my experience it doesn't play well at all with reflection. I haven't dug deeply into many mods to know which mods are using reflection but at least some mods are using it. And again how will you prevent access to the lastlogin file?

[jakj]

The lastlogin file is easy: Just don't save the password. It's annoying to type it in every time, but that's the price of security.

Once that is removed, there is no information within the launch directory that is important to keep secure. Nothing should be available by reflection that isn't available by other means, so there shouldn't be any reason to restrict it.

Really, I just wish there were a way to specify a policy file that says "act like there's no security manager, except for file read/write access, in which case allow only within launch directory or its subdirectories". But there doesn't seem to be: The only way I can find to do a security manager policy file is to add every single picayune little permission one-by-one and that is so much of a pain in the ass and a nightmare to maintain.

[Truculent]

The lastlogin file is easy: Just don't save the password. It's annoying to type it in every time, but that's the price of security.

Relying on your users to not use a feature in order to be secure is a terrible security model, absolutely terrible. Mojang can easily and should do better than this. And we both know that most everyone is going to click that box and save the credentials.

Once that is removed, there is no information within the launch directory that is important to keep secure. Nothing should be available by reflection that isn't available by other means, so there shouldn't be any reason to restrict it.

I think you're misunderstanding my original point - when security manager is used, access to reflection must be granted on a class-by-class basis

http://docs.oracle.com/javase/1.5.0/docs/guide/reflection/spec/java-reflection.doc.html

[jakj]

Well, that does it.

Managed to get things to the point that the launcher would actually start, but when it calls the .start method on the ProcessBuilder object, it uses a relative path (as it should) and Java, for some reason, instead of resolving the location of the command in the ProcessBuilder and checking permission on it, requires you to grant execution permission to ALL FILES. So, fuck Java.

Damnit.

First time since I started learning Java that I found they did something lazy. So I have to give a process permission to execute (meaning run any program or search any directory) on the computer, just to internally execute a subprocess that is in a directory it already has read/write/execute permission for. That is just bullshit bonkers.

I give up. I just give up. I don't know what the fuck to do now. It's a choice between leaving my electronic asshole gaping wide for all comers, or never running modded Minecraft again. Why must things be so difficult...

[Pilchard123]

I still think we should prod Mojang into doing something about it. While I don't really believe this will have a huge effect, if we got enough people to email them about it, at least the issue would be raised. Just distributing a security mod will not be sufficient, not least because you are known as the guy who fixed SirS's thing, and if I do anything to it, all people will have to do is look and see that a) I'm registered over here, and I've talked to you about it.

And don't forget about the JavaCompiler class. That can do some nasty stuff if you don't look out.

EDIT: It seems that that isn't as much of a threat as I thought. I don't know for certain, but it may only work on systems with a JDK installed.