Re: Java: the next platform-independent target

["Wall, Kevin" <Kevin.Wall () qwest com>]

On October 20, 2010, Benjamin Tomhave wrote:

> <snip>
> If I understand this all correctly (never a safe bet), it seems these
> are actual attacks on Java, not on coding with Java. Ergo, this isn't
> something ESAPI can fix, but rather fundamental problems. What do you
> think? Overblown? Legit? Solutions forthcoming?
> <snip>

In a private, off-list email to Ben Tomhave, Kevin Wall incorrectly
speculated in a reply:

> W/out having read this at all (will do later, when I get home), I'd just
> say that there's a lot of safety nets built into Java / JavaEE, but
> most (99%) of development teams don't use them.
>
> Examples (from most to least important IMO) are:
>
>         Java security manager and appropriately restrictive security policy
>         Sealed jars
>         Signed jars
>
> If you are running w/out a security manager, you are really working w/out
> a safety net. I know that Dinis Cruz and I have had this conversation
> a few times and I think we are both in agreement on that matter.

Ben,

When you first referenced these URLs, I thought these were about server-side
exploits, but reading through these, it appears that most of them are
client-side exploits that are attacked using malware applets.  Since
applets do use a Java security manager, that shoots my original theory I
mentioned below. (I would stand behind this conclusion for server-side
exploits though.)

So, you are right about ESAPI not helping here as one is downloading
and running untrusted code in the first place and it's doubtful that
an attacker is going to use ESAPI to protect their victims. :)

However, I think I reached a different conclusion then you did. It
appears that the major issue here is users are not updating their
Java installations either because either they are not aware it is installed
to start with or perhaps because automatic Java updates are
disabled on not installed correctly.

I think the "solution" for this problem (which, IMO, is unlikely, at least
in the near-term future) is that Windows Update needs to include
*all* the software (or at least all the common software that adheres
to some common packaging format) running under a Windows OS.
Most Linux systems already do this. For instance on Ubuntu or OpenSUSE,
if I wish to update Java or Adobe Flash or Acrobat, I don't do anything
different then when I'd update something that is provided by the vendor.
Frankly, the fact that that Windows Update doesn't do this was one major
reason why I've replaced all my Windows instances with various Linux
installs. I used to run Secunia PSI to scan my Windows system, but even
though I knew *what* to patch, doing so was way too painful. I can only
imagine that the typical PC user is much less diligent about keeping
their system patched that I am, which would explain a lot. Java is on
most systems and rarely is patched, ergo, recipe for disaster.

So my conclusion is that these findings say more about the fact that these
systems are not being patched  than it is a poor reflection on the quality
of Java. (The report indicates that this enormous jump in the number of
exploits is "due to the fact that three particular vulnerabilities are
being constantly exploited" and that "These vulnerabilities have been
patched for a while, but the problem is that users fail to update Java
on their system".)

Given the slant of posts to this list, I originally thought these
reports were about JavaEE app servers being vulnerable.  So, my bad
for jumping to conclusions, but I think my new conclusion is that this
is not so much much an issue with Java (the language + VM) as it is
with the way that Java Update (as delivered by Sun / Oracle) sucks.

Regards,
-kevin
--
Kevin W. Wall   614.215.4788            Application Security Team / Qwest IT
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

_______________________________________________
Secure Coding mailing list (SC-L) SC-L () securecoding org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
_______________________________________________