WebApp Sec mailing list archives
Re: [SC-L] By default, the Verifier is disabled on .Net and Java
From: "Michael Silk" <michaelslists () gmail com>
Date: Thu, 11 May 2006 22:20:10 +1000
On 5/11/06, Steve Brown <steve () kabarty com> wrote:
App server ClassLoaders are a law unto themselves. If you try to use an object whose class was loaded from a WAR file, in an EJB for example, you will get a ClassCastException, even though the class is loaded and available, because a different ClassLoader loaded it. This is a whole area of expertise and black magic that takes even respectable Java programmers a fair while to get their head around :) I believe that Stephen de Vries is largely right, because the App Server defines it's own ClassLoaders, it must be using the reflection APIs to do this and that's why you see them behaving differently, however the classes loaded from the javax.* packages (thus, HttpServletRequest, ServletResponse etc) will (probably) be loaded through the standard/System ClassLoader when the App server starts up as opposed to when the specific application is deployed. Thus they have 'static knowledge' of the javax API classes, but do not have 'static knowledge' of the classes you've deployed in your WAR/EAR as these are all loaded by the vendor specific ClassLoader. http://www.theserverside.com/articles/article.tss?l=ClassLoading gives a good article about it, but suffice to say that App server class loading is different to Desktop java classloading which generally uses only one ClassLoader and has a much laxer policy on what it will allow, which is different again to Applet ClassLoading... I'm still not sure how you would exploit any of this for malicious purposes anyway, in order to call a private method in someone elses code you'd have to subvert the .class file containing that private method anyway, in which case simply calling the private method would be the least damage you could do. This, I believe, is why Applets require signing before a browser will allow them to do things like opening network sockets (except back to the host they were loaded from) and writing to local file systems - so that the .class files can't be subverted in this way.
you don't need to subvert class files. you need to review the posted examples. the point is that if you convice _your_ class, that the method you are calling is public, not private, then it's all good at runtime providing the verifier is off. -- Michael ------------------------------------------------------------------------- Sponsored by: Watchfire Methodologies & Tools for Web Application Security Assessment With the rapid rise in the number and types of security threats, web application security assessments should be considered a crucial phase in the development of any web application. What methodology should be followed? What tools can accelerate the assessment process? Download this whitepaper today! https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9h --------------------------------------------------------------------------
Current thread:
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Stephen de Vries (May 11)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Stephen de Vries (May 11)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Steve Brown (May 11)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Michael Silk (May 11)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Charles Miller (May 11)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Stephen de Vries (May 13)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Michael Silk (May 13)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Charles Miller (May 14)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Steve Brown (May 11)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Stephen de Vries (May 11)
- RE: [SC-L] By default, the Verifier is disabled on .Net and Java Jeff Williams (May 11)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Michael Silk (May 11)
- <Possible follow-ups>
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Michael Silk (May 14)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java leichter_jerrold (May 15)