This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I hope this is the right place to ask about this. I was reading in Learning Java about the measures Java goes through to secure code. Something about 3 layers.. Not sure the book is out in my car sorry.
Anyway from what I gather compiled Java code is safe from viruses? I would imagine this is 'more or less'. What I mean is that a virus cannot infect compile Java programs..
Just curious about this. I don't run Windows and there are so very few (6 known I think) Linux viruses. Anyway I just thought this was interesting but perhaps I read it wrong.
I would imagine that it's due to the way Java source is compiled.
Great book by the way, and I'm also getting Head First Java 2nd Edition from Amazon.
Again sorry is this is the wrong place to ask this.
It would be very easy to put a virus in a Java application. You can simply find the main class and add some byte code into the main function. But, no one has done that yet because, outside of the development community, Java applications are not so popular.
You cannot add a virus into a signed Java pplet, because the signing process ensures that the applet cannot be modified
A virus can always infect the JVM too. If a virus infects java.exe, all Java applications will be infected
There are many situations in which Java code is "mobile": applets, JavaWebStart, RMI; and many other situations where external Java code is "hosted" by an application server or other container. In all of these situations, the Java SecurityManager can come into play. The SecurityManager can exert fine-grained control over what the foreign or hosted code can do: it can have restricted file-system access, restricted network access, etc.
Furthermore, besides the SecurityManager, there's the bytecode verifier, which checks bytecodes before they run; it makes sure the machine stack is always balanced, and other crucial checks to ensure that the foreign code can't disrupt the JVM itself.
Finally, the design of the JVM is such that stack-smashing and other means of attack open to native-code viruses are closed to Java programs; it's simply not possible to overflow a buffer and thereby overwrite the a return address on the stack in a Java program the way it is in native code.
So there are quite a few elements to Java seccurity. The situation is a lot better than our friend above seems to think.
Ahh!! I didn't know about JVM protecting itself from attacks from foriegn code. Do you know any place I can read up more on that?.
My understanding of viruses was that one of the techniques is tha a virus injects itself into the executable and modifies the entry table in the header of the executable so that control is first goes to the virus code before the application code is executed. Can't a virus do that with java.exe?
Also, is it not possible to add some byte code into the main class that can call some nefarious native code every time the Java application starts? I agree that won't be useful with an unsigned applet because the SecurityManager will block any access to native code/local resources, and this won't work with signed applets, because the JVM will catch any manipulation of byte code. But, what about Java applications?
Joined: May 27, 2004
Sorry it took me so long to reply. However I thank you for clearing that up for me. That's pretty much what I read, but I just needed some clarification.