Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Java Coding Guidelines: Java finger-wagging

 
Yvette Schat
Ranch Hand
Posts: 83
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello again,

Java is regularly picked on when it comes to security. In some interesting security
podcasts like 'Security Now' for example this is often the case...

Obviously this comes up in discussions amongst colleagues. As I love Java can you
give me some arguments to counter this finger-wagging?

Best regards,

Yvette
 
David Svoboda
Author
Greenhorn
Posts: 13
5
Debian Java Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yvette:

I wish Java's current security problem was called Java's sandbox problem instead. Java's security sandbox makes it possible to have trusted code and untrusted Java code in the same program. More generally, it let people run untrusted Java applets on the web. Applets that could show you dancing bunnies, but couldn't touch your files. Or your network. People trusted Java's security sandbox for 15 years before it was widely exploited. This sandbox problem is the source of most of Java's current troubles.

It's a really arcane problem, too. No other language allows trusted & untrusted code to run in the same program. Even programs with plug-in architectures, such as Firefox, assume you only install & run a plugin if you trust it. So developers aren't used to having untrusted code in their programming environment.

But if your Java program does not use this sandbox problem, these troubles don't affect you. More to the point, if you don't permit untrusted code to run in your porgram, these troubles don't affect you. So if you're writing a desktop application or Android app, these troubles don't affect you. They only affect Web applet & servlet developers.

So to run Java safely, you should assume your Java program does not permit untrusted Java code to run alongside its trusted code. If you write code in any other language you already assume this.

 
Ulf Dittmer
Rancher
Posts: 42968
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Svoboda wrote:They only affect Web applet & servlet developers.

I think this needs a bit of elaboration, mentioning applets and servlets as if they faced the same security issues is misleading IMO. Applets are Java code from an unknown source run on my desktop (effectively), that's why the proper functioning of the sandbox is so critical: because code of unknown provenance otherwise has access to my files.

Web apps, on the other hand, are generally written and run by the same organization, so even in the case of a broken sandbox it would be my code that could access my files - not a big deal. (Unless we're talking about shared hosting, where person X's web app runs on person Y's server along with the other folks' web apps. That is a different case, in which the sandbox once again becomes critical. But these two cases need to be differentiated.)
 
David Svoboda
Author
Greenhorn
Posts: 13
5
Debian Java Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Ulf. One of the problems with applets is that (until recently) there was no way to indicate that you trust the applet you are running. Oracle's recent updates to Java have provided users with the ability to trust (or not trust) a Web applet. This does place extra burden on the users, but eases the burden on certain applets....in particular applets created by the user's company.
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65220
95
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I too am interested in an answer to Ulf's questions on servlets. Could you address those?
 
Dean Sutherland
Author
Greenhorn
Posts: 3
5
C++ Java Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ulf Dittmer wrote:
David Svoboda wrote:They only affect Web applet & servlet developers.

I think this needs a bit of elaboration, mentioning applets and servlets as if they faced the same security issues is misleading IMO. Applets are Java code from an unknown source run on my desktop (effectively), that's why the proper functioning of the sandbox is so critical: because code of unknown provenance otherwise has access to my files.

Web apps, on the other hand, are generally written and run by the same organization, so even in the case of a broken sandbox it would be my code that could access my files - not a big deal. (Unless we're talking about shared hosting, where person X's web app runs on person Y's server along with the other folks' web apps. That is a different case, in which the sandbox once again becomes critical. But these two cases need to be differentiated.)


We've seen a number of issues regarding shared hosting of web apps. See, for example CVE-2009-0783; detailed explanation on our wiki at SEC03-J. As Ulf says, that brings sandbox issues back into play. However, even web apps written and run by a single organization may require proper functioning of the sandbox. This is most likely to be an issue for public-facing web apps that provide services to users outside the organization; it's rarely an issue for purely internal web apps. Exceptions include applications in national security agencies (think Secret and Top Secret data) where even internal users should be prevented from seeing data for which they lack clearance.

My personal bottom line for responding to the "Java finger-wagging" is that Java is significantly more secure than most other languages. That said, successful support for mixing trusted and untrusted code (e.g., sandboxing) is really hard; most other languages don't even try! And some popular use-cases for Java—executing downloaded applets and shared hosting of web-apps—fundamentally depend on getting the sandboxing exactly right. That's where the headline vulnerabilities have appeared.
 
David Svoboda
Author
Greenhorn
Posts: 13
5
Debian Java Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Apache Tomcat is a "servlet container". Which is to say, it provides a framework that enables servlets to be accessed on the web. Tomcat has several mechanisms to allow a servlet to be deployed, including remote uploading. If you're authorized, you can package up your servlet, go to a Tomcat form, and upload it, and your servlet is now live.

Tomcat uses Java's SecurityManager to protect the servlets from itself and from each other. Since this is the same SecurityManager used by applets, it has the same vulnerabilities. A malicious servlet could bypass the sandbox and run Java code with the same privileges as Tomcat itself. Crashing Tomcat would therefore be easy, and a suitably advanced malicious servlet could probably corrupt Tomcat to misbehave, perhaps tricking users of other servlets into submitting sensitive info (such as passwords).

The remaining question is how an attacker gets a malicious servlet onto a running Tomcat instance. Tomcat does have various protection mechanisms to decide who gets to deploy servlets, and more are provided by its operating platform. Clearly deploying a malicious applet is easier than deploying a malicious servlet, because your attacker has to convince some Tomcat instance to deploy their malicious servlet.

I'm gonna stop here because I've reached the limits of my Tomcat knowledge
 
Ulf Dittmer
Rancher
Posts: 42968
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A production servlet container will typically not have any means of deploying web apps short of access to the command line and the file system. That is to say, any "manager
Web app" or similar would responsibly be turned off. So an attack on this is in an entirely different ball park than a rogue applet. That's why I said mentioning both in the same sentence needs qualification.
 
Dhruv Mohindra
Author
Greenhorn
Posts: 11
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ulf,

The distinction between the risk for an applet and servlet is definitely worth noting as you explained.

Ulf Dittmer wrote:
David Svoboda wrote:They only affect Web applet & servlet developers.

Web apps, on the other hand, are generally written and run by the same organization, so even in the case of a broken sandbox it would be my code that could access my files - not a big deal.


Although it sounds overkill to sandbox web apps, it can provide an additional layer of defense. For example, in the scenario you cite above, a path traversal vulnerability in code could compromise the file system contents unless the application's IO access is specifically restricted to a folder or file through the use of a Java security policy and security manager. A hole in the sand-boxing mechanism would be detrimental in such cases.

 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic