Assume I have a webpage where people submit java source code (a simple class).
I want to compile and run the code on my server, but naturally I want to prevent people from harming my server, so how do I disable java.io.* and other functions/libraries of my choice?
A regexp on the source code would be one way, but it would be "nicer" if one could pass some argument to javac or java.
(This could be useful when creating an AI competition or something where one implements a single class, but I want to prevent tampering with the java environment.)
If you are in complete control of the JVM, then you can use security policies to do this. It's the same approach taken by web browsers when they host applets.
http://java.sun.com/j2se/1.5.0/docs/guide/security/permissions.html
Hope this helps.
Depending on your intent, you might be able to speak with Nick Parlante, who runs javabat.com - it does pretty much exactly what you're describing. I don't know whether he's willing to share his solution, but he might be able to give you some specific help.
My advice is don't do it. At least, don't do it unless you are willing and prepared to accept the consequences of the machine that runs your server being hacked. And maybe other machines on the same network.
The Google App Engine uses an approach where classes are white listed - that is, they are probably either not loaded, or the classes themselves changed and the libraries recompiled, so that no IO, or other system calls can be made. perhaps you could try this by recompiling a jvm like http://jikesrvm.org/.
You can always run the code in a custom classloader. This allows you full control about what you will accept to load.
Related
A bit of a noob-who-tries-to-get-a-glimpse-of-something-without-making-homeworks-first question...
Suppose I'd like to include a JVM on a closed source O.S./hardware to be able to provide extended functionalities to customers with addon java applets, and that I'd want to be the only available source to develop and sell addon apps... then is it feaseable to easily implement such a mechanism by simply forcing embedded JVM to only allow execution of apps signed with my digital sign?
In other words I'd just like to know if this is an easy to implement, already proven to work, widely accepted path or just plain BS (for reasons you are free to not tell!) :)
It sounds like what you're wanting is class signing. The startup code for your application can install a SecurityManager to ensure that only classes signed by keys matching some particular criteria can be loaded.
Adding my own answer to get feedback on the following solution, which seems to be the most fitting with my question:
Could Java system policy file be the answer?
As far as I can understand from reading the documentation at http://docs.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html you can basically implement code execution permission policy in 2 ways:
1) implementing and extending permission policy at runtime (what #chrylis refers to).
2) using a default system policy file (java.home\lib\security\java.policy)
The second approach seems easier to implement and kind of more "static" which is a good thing given my use-case because I only need JVM to check that digital sign of app is mine to allow it to run, and will never ever need to extend this policy in any possible way.
So I am not sure yet but given my prerequisites this approach might be what I was looking for in my question... If you have any thoughts just add them, thanks.
I want to create a Java-based website that will execute completely untrusted code from third parties. This third-party code will need to be able to access websites on the Internet, but not, for example, attempt a DoS on them.
I can choose the language, but if its obscure it will hurt adoption of the service I'm building.
Can anyone provide some pointers as to open source tools I should investigate?
Are you thinking of something like the Google App Engine? They do this for Java by providing a "sandbox" where the app has access only to carefully restricted subset of the Java API. You might take a look at their JRE White List for ideas. (They also provide other languages.)
Yahoo App Platform and Amazon Web Services provide similar functionality, but not in Java (which, from your tag, I assume is your main interest).
The key to do this with Java code, of course, is defining a SecurityManager and then carefully specifying the policy. Aside from that, you'd host on a Linux system and use a chroot jail -- or better yet, a chroot jail on a virtualized system.
You don't have to worry about someone using your single server to launch a DDOS attack, though, by definition!
First things first, you need to build an excellent jail or sandbox for your application. Virtualization can help, but even within a guest VM there are a lot of operations you wouldn't want your untrusted code to perform.
So investigate mandatory access control such as AppArmor, SElinux, TOMOYO, or SMACK. Any of these can lock down your server code to only a subset of allowed operations. There are patches available that can lock your application to a subset of system calls that is probably worth investigating as well. (Since I've worked on AppArmor for almost a decade, it's the tool I know best. It's also the tool I think best suited for the task, but SMACK's utter simplicity is really appealing.)
You can perform rate limiting at the firewall level to try to limit the amount of outside annoyances that your code hosting can cause. Rate limiting isn't the same as preventing :) but it gives you an opportunity to see obvious attempts to do stupid things in your logs.
Wait you all.
There is no reason for #sanity to look for 3rd party solutions, because Java already has a policy mechanism which allows untrusted code to access only a given subset of the Java API. See package java.security and SecurityManager. It allows you to say the JVM, "this app must have permission to access this stuff but not this other one".
But I think #sanity wants to grant a given permission to run untrusted code, without allowing it to do harmful things with that permission...
I'm not sure if I understand your question. But from what I understand you just need the user to be able to execute code (in a java-based website, however the code doesn't need to be java), in that case have you considered letting the user execute only client-side code (ie javascript)? This way the only machine they can harm is their own. You can read more about how other websites handle malicious code here and you can read about the few dangers of letting users execute JS here.
For my program i need to register key events that happen without the application having the focus. (i.e. internet explorer having the focus) I have been looking and people say you can do it with jni; however, is there anyway to do it without it?
Can someone give me a link of a really good jni example? the ones i have looked at so far havent been very helpful
JIntellitype (which is an Apache 2.0 license) will do this for you in Windows. JxGrabKey appears to be a valid solution for Linux. I'm not aware of a cross-platform solution. (These still use JNI, but they'll abstract the details for you)
http://melloware.com/products/jintellitype/index.html
http://sourceforge.net/projects/jxgrabkey/
Do you want to create a key logger? No, it is not possible without JNI or using some library which wraps the JNI away for you.
The only way in Java to do things outside of your own Frames/Windows is using java.awt.Robot, but this only allows screenshots and sending input to other programs, not capturing input.
Thinking outside of the box here...
What possible basic approaches could be taken in an effort to create a Flex component that could run Java?
I know I can easily use flex to browse to or launch a Java app, but there are things I can only do if I can run the Java from WITHIN an MXML Component.
I the strictest sense, I know it's not impossible (ie: if you had all the source code for flex and for the jvm), but what's the least impractical means to this end?
Edit:
Lots of people are interested in the reason WHY someone might want to do this. I see it as irrelevant to HOW to do it, but here goes: I have over 100 proprietary pixel-reading windows programs that I could port to Mac in this way, much easier than any other way. But instead of arguing the premises, the winning answer will ignore the reasons why, and focus on the HOW.
Showcase your creativity.
This sounds crazy insane to me. My answer is to not go down this route. It may be a fun technical challenge for fun; but has little practical value that I can see.
Answer the question, Why would you want to run a JVM inside a Flex app?
Also, How would you use a Flex App to browse or launch a Java App? As best I understood, the security sandbox of the browser prevents you from launching other local applications.
I don't believe you are correct about not being able to accomplish certain things you "can only do if I can run the Java from WITHIN an MXML Component". With proper communication set up, you can have the Applet and the SWF simply communicating with each other through an external set of processes.
The easiest way to accomplish this is to "fake it". Load a Java Applet (This should be possible by use of the SWF's ExternalInterface API -- generate the Object tag and add it to the HTML around the swf. To make this even more convincing, use CSS to have to Applet appear "on top" of the swf. ) and have it communicate with the original swf through JavaScript calls. If that is not possible, then it may be possible to have the Java Applet generate some form of pseudo-server which the swf could then communicate with.
If neither of those work, then there is always the SWF bytearray syntax. It would need to load a ByteArray, manipulate the internal data, and then send it... somehow.
A while back I prototyped something like this. I exposed a window / native app via a VNC server and then used an open source VNC client library to connect to the VNC server. It was totally hacky but it worked. Performance was not great but was usable. Here is the Flash VNC client library I used:
http://www.wizhelp.com/flashlight-vnc/index.html
I'm with Flextras, you need to explain why before a reasonable solution can be proposed.
Unreasonable solution:
Implement the jvm in AS3. Read jars in as bytearrays. Pass the bytearrays to you new jvm.
Reasons for unreasonableness:
Implementing even a partial jvm would be at least thousands of man hours of work.
Running a virtual machine inside of Flash's already (relatively) slow vm would be like riding a golf cart that's being towed by a tortoise: either one by itself would be faster.
You can interface between Air & a Java app using merapi (although that's just communication, not actually running the api inside air)
Is there a way to deploy a Java program in a format that is not reverse-engineerable?
I know how to convert my application into an executable JAR file, but I want to make sure that the code cannot be reverse engineered, or at least, not easily.
Obfuscation of the source code doesn't count... it makes it harder to understand the code, but does not hide it.
A related question is How to lock compiled Java classes to prevent decompilation?
Once I've completed the program, I would still have access to the original source, so maintaining the application would not be the problem. If the application is distributed, I would not want any of the users to be able to decompile it. Obfuscation does not achieve this as the users would still be able to decompile it, and while they would have difficulty following the action flows, they would be able to see the code, and potentially take information out of it.
What I'm concerned about is if there is any information in the code relating to remote access. There is a host to which the application connects using a user-id and password provided by the user. Is there a way to hide the host's address from the user, if that address is located inside the source code?
The short answer is "No, it does not exist".
Reverse engineering is a process that does not imply to look at the code at all. It's basically trying to understand the underlying mechanisms and then mimic them. For example, that's how JScript appears from MS labs, by copying Netscape's JavaScript behavior, without having access to the code. The copy was so perfect that even the bugs were copied.
You could obfuscate your JAR file with YGuard. It doesn't obfuscate your source code, but the compiled classes, so there is no problem about maintaining the code later.
If you want to hide some string, you could encrypt it, making it harder to get it through looking at the source code (it is even better if you obfuscate the JAR file).
If you know which platforms you are targeting, get something that compiles your Java into native code, such as Excelsior JET or GCJ.
Short of that, you're never going to be able to hide the source code, since the user always has your bytecode and can Jad it.
You're writing in a language that has introspection as part of the core language. It generates .class files whose specifications are widely known (thus enabling other vendors to produce clean-room implementations of Java compilers and interpreters).
This means there are publicly-available decompilers. All it takes is a few Google searches, and you have some Java code that does the same thing as yours. Just without the comments, and some of the variable names (but the function names stay the same).
Really, obfuscation is about all you can get (though the decompiled code will already be slightly obfuscated) without going to C or some other fully-compiled language, anyway.
Don't use an interpreted language? What are you trying to protect anyway? If it's valuable enough, anything can be reverse engineered. The chances of someone caring enough to reverse engineer most projects is minimal. Obfuscation provides at least a minimal hurdle.
Ensure that your intellectual property (IP) is protected via other mechanisms. Particularly for security code, it's important that people be able to inspect implementations, so that the security is in the algorithm, not in the source.
I'm tempted to ask why you'd want to do this, but I'll leave that alone...
The problem I see is that the JVM, like the CLR, needs to be able to intrepert you code in order to JIT compile and run it. You can make it more "complex" but given that the spec for bytecode is rather well documented, and exists at a much higher level than something like the x86 assembler spec, it's unlikely you can "hide" the process-flow, since it's got to be there for the program to work in the first place.
Make it into a web service. Then you are the only one that can see the source code.
It can't be done.
Anything that can be compiled can be de-compiled. The very best you can do is obfuscate the hell out of it.
That being said, there is some interesting stuff happening in Quantum Cryptography. Essentially, any attempt to read the message changes it. I don't know if this could be applied to source code or not.
Even if you compile the code into native machine language, there are all sorts of programs that let you essentially decompile it into assembly language and follow the process flow (OlyDbg, IDA Pro).
It can not be done. This is not a Java problem. Any language that can be compiled can be decompiled for Java, it's just easier.
You are trying to show somebody a picture without actually showing them. It is not possible. You also can not hide your host even if you hide at the application level. Someone can still grap it via Wireshark or any other network sniffer.
As someone said above, reverse engineering could always decompile your executable. The only way to protect your source code(or algorithm) is not to distribute your executable.
separate your application into a server code and a client app, hide the important part of your algorithm in your server code and run it in a cloud server, just distribute the client code which works only as a data getter and senter.
By this even your client code is decompiled. You are not losing anything.
But for sure this will decrease the performance and user convenience.
I think this may not be the answer you are looking for, but just to raise different idea of protecting source code.
With anything interpreted at some point it has to be processed "in the clear". The string would show up clear as day once the code is run through JAD. You could deploy an encryption key with your app or do a basic ceasar cipher to encrypt the host connect info and decrypt at runtime...
But at some point during processing the host connection information must be put in the clear in order for your app to connect to the host...
So you could statically hide it, but you can't hide it during runtime if they running a debugger
This is impossible. The CPU will have to execute your program, i.e. your program must be in a format that a CPU can understand. CPUs are much dumber than humans. Ergo, if a CPU can understand your program, a human can.
Having concerns about concealing the code, I'd run ProGuard anyway.