Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Using type- and memory-safe languages like Java and Scala for server applications gave me the confidence of having a basic level of security (e.g. compared to C). Now with the recent wave of Oracle Java vulnerabilities I noticed that most of them apply for applets in web-browsers and only a minority of them apply to servers. However, is JVM in general (still) a good choice for high secure server applications? Are other JVMs (e.g. from IBM) more secure than Oracle's for this purpose?

I'm not asking on applets, web browser, desktops but am only interested in server's security.

share|improve this question
    
Hello and welcome to IT Security! Your question seems a bit too open-ended, and might inspire debate. Please refer to the FAQ on what questions aren't expected to be properly answered and why not. But I see some parts of it that certainly need answering, as it suggests some misapprehensions regarding what type-safe and memory-safe actually mean for languages, compilers and their memory managers in terms of system and application level security. If you could re-write it to be more specific for the 2nd part, that'd be fab. Thanks! –  TildalWave Mar 19 '13 at 4:50
    
possible duplicate of Should I be disabling Java? –  Terry Chia Mar 19 '13 at 5:01
5  
@TerryChia It's not a duplicate because it refers to browser security. A server scenario was mentioned in a single sentence of an answer only. –  user8117 Mar 19 '13 at 7:11

3 Answers 3

Java is fine for servers. The security issues with Java are actually issues with the Java applet model, in which your JVM (in your browser) is meant to run potentially hostile code (i.e. code "from the Web") and yet somehow prevent that hostile code from doing bad thing. The applet model is a bit like running the applet code in a virtual machine, except that the isolation layer is done with the language itself and with safeguards in the standard library. It turns out that trying to do a sandbox that way is very hard, because you have to include explicit controls in every potentially dangerous library class and method, and there are thousands of these. All the Java vulnerabilities which have hit the news in the last years are about that: some standard library code which did not filter calls with enough robustness, in case the caller is an hostile applet.

None of this applies to Java on a server. On a server, that's your code, presumed non-hostile, and with full access to the standard library. Running Java code on your server is no worse (for security) than running C or C++ code; actually it is arguably better because the inherent protections of the Java language (garbage-collector based memory management, strong types and array bounds checks) make it more robust with regards to some categories of bugs like buffer overflows. Namely, consequences of a buffer overflow are more constrained (the buffer is not actually overflowed; an exception is thrown instead), and the GC allows for much easier handling of character strings, something which is a fertile source of buffer overflows when writing C code.

The same reasoning applies to .NET and its various languages (C#, VB...).

share|improve this answer

The Java Runtime Environment can be run using a Security Manager if you want to restrict certain access to certain part of the application (depending on the code that is running and on the authentication status).

This can be enabled in Apache Tomcat or in JBoss for example.

The policy and permissions system is a complex topic, and is documented here.

Admittedly, the system isn't perfect since of the vulnerabilities you refer to about applets occur when the applet "escapes" its security manager. This can happen if there's a bug in the security manager itself (obviously a problem) or if the policy is too loose.

In that respect, a server environment differs from an applet environment in that the applet environment is installed with a one-size-fits-all policy: something aiming to be good enough to restrict bad behaviour while enabling most features, without knowing what code is going to be run nor in which exact environment. A server environment is less vulnerable in that respect, since you may be able to customise your policy to address your specific needs (e.g. allow connections to your specific database server but no other outgoing connections).

Security managers tend not to be enabled by default in webapp containers, but if you need to, you can configure the policies as necessary.

share|improve this answer

Yes, JVM and similar environments reduce the risk of memory-corruption vulnerabilities, although it should be noted that these kind of problems can also occur at VM level (for example CVE-2013-2420)

The recent wave of Java vulnerabilities are indeed focused on client-side applets, but it also should be noted that there have been ways to exploit these problems on server side (like through the RMI protocol). Oracle doesn't always point this out in their advisories:

http://seclists.org/bugtraq/2013/Feb/15

Regarding the security of the different JVM implementations the SE-2012-01 project of Security Explorations seems like a good starting point:

http://www.security-explorations.com/en/SE-2012-01-details.html

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.