Re: [SC-L] Java: the next platform-independent target
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.4788Application 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 ___
Re: [SC-L] Java: the next platform-independent target
Ben, These threats are only relevant for client-side Java, for the most part. It's my opinion that all enterprises should remove Java from all clients. Java is most commonly deployed server-side which has a completely different threat model than client side Java. A lot of smart people disagree with me here - but the history of Java sandbox problems, data theft though reflection, the weak security policy mechanism, etc, backs up my recommendation. Oracle is one of the most irresponsible large technical companies from a product security perspective, so I have no hope that this will get better. Abort Java on the client, and please support forking Java. - Jim -Original Message- From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On Behalf Of Benjamin Tomhave Sent: Wednesday, October 20, 2010 7:24 PM To: SC-L@securecoding.org Subject: [SC-L] Java: the next platform-independent target All these platform-independent attacks are starting to get exhausting, no? Now that Adobe has come up with sandboxing for Reader and actually started responding to threats, it seems that the smart adversaries have moved to a new platform: Java. Stories are below, mostly deriving from Microsoft's latest Intelligence Report (this one has a botnet focus - a topic on which they've invested a ton of resources). 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? The rise of Java exploits http://www.net-security.org/secworld.php?id=10014 Have you checked the Java? http://blogs.technet.com/b/mmpc/archive/2010/10/18/have-you-checked-the-ja va.aspx Java: A Gift to Exploit Pack Makers http://krebsonsecurity.com/2010/10/java-a-gift-to-exploit-pack-makers/ Announcing Microsoft Security Intelligence Report version 9 http://blogs.technet.com/b/mmpc/archive/2010/10/13/announcing-microsoft-se curity-intelligence-report-version-9.aspx cheers, -ben -- Benjamin Tomhave, MS, CISSP tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] I ran into Isosceles. He had a great idea for a new triangle! Woody Allen ___ 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 ___ ___ 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 ___
Re: [SC-L] Java: the next platform-independent target
On Thu, 21 Oct 2010, James Manico wrote: A lot of smart people disagree with me here - but the history of Java sandbox problems, data theft though reflection, the weak security policy mechanism, etc, backs up my recommendation. Given the history of security problems in the PHP interpreter itself, and the occasional issues in Perl, and don't forget some of the tidbits in ASP.Net, maybe all those should be tossed out as well, and we should all move back to C. ;-) Compilers/interpreters are software, too, and so are going to be subject to vulnerabilities. (Not that I'm disagreeing with strategies that reduce attack surface, such as disabling client-side functionality.) - Steve ___ 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 ___
[SC-L] ISO/IEC 27034 application security guideline
Greetings SC-L folks, I don't participate in standards bodies, so I'm not very familiar with their inner workings and such. However, a colleague has pointed me to an ISO standard under development that will describe an application security development process. I visited the site (http://www.iso27001security.com/html/27034.html) and didn't find much in the way of documentation, other than a list of really ambitious plans for the future. So my question here is this: anyone here involved in this standards effort? If so, would you mind sharing with us a high level overview of where they are in their efforts and when the world is likely to start seeing output from the effort? Much appreciated. Cheers, Ken - Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com Follow us on Twitter at: http://twitter.com/KRvW_Associates PGP.sig Description: This is a digitally signed message part ___ 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 ___
Re: [SC-L] Java: the next platform-independent target
PHP interpreter itself, and the occasional issues in Perl, and don't forget some of the tidbits in ASP.Net, maybe all those should be tossed out as well, and we should all move back to C. ;-) I think the deprecation of these technologies for an enterprise is a wise idea. :) How can a large enterprise use PHP or ASP for security-critical applications with a straight face? Let's move forward to Ruby on Rails, Enterprise Java, .NET and other modern frameworks that are more mature from a security centric POV. I have no problem with server-side Java, especially when using a modern security framework like Spring Security or (wait for it) ESAPI. But client-side Java? Flash? There are a few large organizations who have banned both from their clients and they are more secure for it. -Jim Manico http://manico.net On Oct 21, 2010, at 10:58 PM, Steven M. Christey co...@linus.mitre.org wrote: PHP interpreter itself, and the occasional issues in Perl, and don't forget some of the tidbits in ASP.Net, maybe all those should be tossed out as well, and we should all move back to C. ;-) ___ 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 ___
Re: [SC-L] Classification/Enumeration of Software Defect Mitigations
You may wish to consider OWASP ASVS mitigation recommendations. You can word-smith negative recommendations of what •not• to do to come up with a great list of defensive recommendations. For example, instead of saying Never put sensitive data in HTTP GET requests I'd like to see us shift to control-centric language like Only use HTTPS POST to transmit sensitive data. And in general Steve, a list of mitigations implies tactical approaches to Application Security (ie: fix specific flaws) which is fairly limited. I'd love to see this expanded to cover general defensive coding techniques and good security design principles that help dev's build secure apps from day 1. And Steve, you only see me pop up when I have a criticism. But as I said when we went hiking on Kauai, I think you and team are doing outstanding work and I'm thankful for all of your efforts. Regards, -Jim Manico http://manico.net On Oct 22, 2010, at 12:39 AM, Steven M. Christey co...@linus.mitre.org wrote: All, Both WASC and the MITRE CWE team have begun exploring the feasibility of enumerating or classifying the types of mitigations that are used to fix software defects/weaknesses. Does anybody know of such work in this area? (We can draw from sources such as McGraw/Viega Building Secure Software, and 'indirect' sources such as ESAPI, but I was wondering if there was something that was a little more focused on mitigations.) CWE status: http://www.webappsec.org/lists/websecurity/archive/2010-10/msg00065.html WASC status: http://www.webappsec.org/lists/websecurity/archive/2010-10/msg00066.html Thanks, Steve ___ 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 ___ ___ 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 ___
