WebApp Sec mailing list archives
Re: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code
From: Stephen de Vries <stephen () corsaire com>
Date: Wed, 29 Mar 2006 15:51:07 +0700
Hi Dinis, On 29 Mar 2006, at 05:52, Dinis Cruz wrote:
Thanks for confirming this (I wonder how many other other Java developers are aware of this (especially the ones not focused on security)).
Most I've worked with aren't really aware of the security manager, never mind bytecode verification. It is an issue, but the security risk in the real world may be a bit overstated. If I were a maliciously minded attacker that wanted users to execute my evil Java program, I wouldn't need to mess about with the lack of verification, I could just write evil code in perfectly verifiable format and rely on users to execute it. Can anyone come up with attack vectors that exploit lack of verification on downloaded code that couldn't be exploited by other (easier) means?
Stephen, do you have any idea of what is the current percentage of 'realworld' Java applications are executed: a) with verification b) on a secure sandbox
Very few. As Jeff mentioned some Java Application servers ship with a security policy enabled, but the policy doesn't restrict anything (e.g. JBoss), other's show you how to run with a sec policy, but don't apply it by default (e.g. Tomcat). In some cases, with the more complex app servers a sec policy would be of little security benefit because the server needs so much access in order to function properly that the policy could be considered completely open.
In some ways I think we're applying double standards here. Just because a virtual machine offers the facility for defining a security policy and verification doesn't mean that it _has_ to use it. There are native executable programs that I trust, so why should a program that runs in a VM be subject to more stringent security controls just because they're available? IMO whether code needs to be sandboxed and controlled by a policy should be decided on a case by case basis rather than a blanket rule.
Note that for example I have seen several Java Based FinancialApplications which are executed on the client which either require localinstallation (via setup.exe / App.msi) or require that the user grants that Java application more permissions that the ones allocated to a normal Sandboxed browser based Java App.
This is quite common for an app, and granting more permissions is fine as long as those are tightly controlled by the java security policy.
Humm, this is indeed interesting. Ironically, the 1.1 and 2.0 versions of the CLR will thrown an exception in this case (even in Full Trust).Since verification is not performed on that .Net Assembly, the CLR mightpick up this information when it is resolving the method's relative address into the real physical addresses (i.e. during JIT).Using the same code with an Applet loaded from the filesystem throws an IllegalAccessError exception as it should.What do you mean by 'Applet loaded from the filesystem'? Where? In a Browser?
If you load an applet in a browser using a url such as: file:///data/ stuff/launch.html then no verification is performed.
But if you access the applet using http/s then it will be verified. cheers, -- Stephen de Vries Corsaire Ltd E-mail: stephen () corsaire com Tel: +44 1483 226014 Fax: +44 1483 226068 Web: http://www.corsaire.com ------------------------------------------------------------------------- This List Sponsored by: SpiDynamicsALERT: "How A Hacker Launches A Web Application Attack!" Step-by-Step - SPI Dynamics White Paper Learn how to defend against Web Application Attacks with real-world examples of recent hacking methods such as: SQL Injection, Cross Site Scripting and Parameter Manipulation
https://download.spidynamics.com/1/ad/web.asp?Campaign_ID=701300000003gRl --------------------------------------------------------------------------
Current thread:
- RE: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Jeff Williams (Mar 27)
- Re: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Stephen de Vries (Mar 27)
- Re: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Dinis Cruz (Mar 28)
- [Full-disclosure] Re: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Dinis Cruz (Mar 28)
- RE: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Eric Swanson (Mar 27)
- Re: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Dinis Cruz (Mar 28)
- [Full-disclosure] Re: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Dinis Cruz (Mar 28)
- Re: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L]4 Questions: Latest IE vulnerability, Firefox vs IE security,Uservs Admin risk profile,and browsers coded in 100% Managed Verifiable code ol (Mar 27)
- <Possible follow-ups>
- Re: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Stephen de Vries (Mar 29)
- Re: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Stephen de Vries (Mar 27)