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 _______________________________________________