I want to to detect whether a given program can perform malicious operations like forking , interprocess piping , input/output redirection, file handling etc.
Actually I am developing a program that checks java codes and do not want the coder to harm my code checker system in any way.
What are the packages I should look for in code to ensure this ?
Thanks in advance... !
views:
84answers:
4Much of the OS-interaction functionality is provided in java.lang.Runtime
and java.lang.System
. Note that these wouldn't require imports, because they're in the java.lang
package.
But... if you're just analyzing the code, why would you care what calls it contains? Perhaps you should be looking at Java Security instead of which classes get called.
You should think about checking also all methods marked as "native".
Would your checks be at compile time or at runtime?
If you check at runtime, you could use a security manager with permissions. Have a look at Security Manager Tutorial. There is a wide list of permissions. You can disallow file access, even open frames.
As for base classes, you would have to be careful with
java.lang.Runtime
andjava.lang.System
,java.lang.ProcessBuilder
. These createjava.lang.Process
. Alsojava.io.File
,java.io.FileDescriptor
, maybe even Sockets andjava.nio.*
operate on the OS/file system.I would also disallow reflection,
java.lang.reflect.*
, and some methods ofjava.lang.Class
are reflective too. Loading classes by name might workaround your checks. Some classes injava.beans.*
are using reflection as well.Depending on your needs, you might even want the user code to run in a sandbox. But that might go too far for you. Checking for class usage (constant pool) might be an easy way.
As Colin HEBERT pointed out before,
native
is also dangerous. But some of them are definitely needed, likeObject
's methods.
Short answer: java.lang. I believe that's the only "out of the box" package that includes classes that give you access to OS functions. Well, I'm assuming here that you don't include I/O as "OS-related" stuff. If you do, then you'd also have to include the java.io, javax.swing, and a couple of other packages.
Longer answer: A programmer could write his own JNI functions that interact with the OS and put them in any package he likes. Trying to identify this could be quite tricky. Well, I guess you could say that any "native" function is automatically suspect.