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
--------------------------------------------------------------------------
