On 5/11/06, Steve Brown <steve_at_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
--------------------------------------------------------------------------
Received on May 11 2006
Intro
