Hi Benjamin,
While it might be possible to modify the name loaded (if you
have access to that, but not access to the code) your modified class
would have to implement the appropriate interface or extend the
appropriate abstract class to be executed successfully be the loading
class.
Hence, to do this (implement interface or extend ...) you have
to have access to the code in some fashion, so it reduces the risk a
bit. Not fully, however, as it may be possible to get your hands on an
early release of the interface and compile against that.
In any case, you must know the code somewhat, and hence be able
to craft your malicious code to deal with the environment.
Further, if the developer realised that this would be a issue
(un-trusted loading) he could utilised the SecurityManager to restrict
the loaded class to doing certain things.
As for issues relating to getting access to these types of
property files - of course, it depends on your setup ... Personally I
store this information in the database, and unauthorised access to that
would cause more troubles.
-- Michael
-----Original Message-----
From: V.Benjamin Livshits [mailto:livshits@cs.stanford.edu]
Sent: Saturday, 13 November 2004 10:26 AM
To: webappsec@securityfocus.com
Subject: Trouble with Reflection
I've seen a large number of cases where components of an application
(such as individual servlets, beans, plugins, etc.) are loaded
reflectively. The names used for reflective invocation are ofen read
from confiration files and such.
It seems that if the intruder has access to that configuration file, but
not perhaps to the rest of the application, he should be able to
substitute malicious remote implementations for the classes to be
loaded. I guess, that's somewhat similar to loader hijacking attacks.
Are there inteersting situations or scenarios where application
configuration might fall under malicious user's control? By interesting
I mean something other than just storing these files in easily
accessible location.
Have there been any attacks along these lines?
Thanks,
-Ben
**********************************************************************
This email message and accompanying data may contain information that is
confidential and/or subject to legal privilege. If you are not the intended
recipient, you are notified that any use, dissemination, distribution or
copying of this message or data is prohibited. If you have received this email
message in error, please notify us immediately and erase all copies of this
message and attachments.
This email is for your convenience only, you should not rely on any information
contained herein for contractual or legal purposes. You should only rely on
information and/or instructions in writing and on company letterhead signed by
authorised persons.
**********************************************************************
