risks of allowing uncontrolled instantiation of classes?

[Rogan Dawes]

Hi,

I was performing a security review of a web application, and encountered
a form where the class to use to format a report was specified as a form
variable.

i.e. the code was doing

Class.forName(userInput).newInstance();

In my mind, this could be open to abuse. The "attacker" could tell the
app server to create an instance of ANY class he chooses, so long as
that class exists on the class path.

In this particular case, the app server was Tomcat 4.

Can anyone think of a way that this ability could be exploited to gain
additional access to the system?

e.g. reading or writing a file, opening a network connection, starting
up a new servlet, etc?

Looking at it logically, I don't think that it is SUCH a big deal. But
then, I don't know all the classes that exist by default on a Tomcat
classpath.

If anyone could prove me wrong, that would be good! ;-)

Regards,

Rogan

 

[Chris Uppal]

Looking at it logically, I don't think that it is SUCH a big deal. But
then, I don't know all the classes that exist by default on a Tomcat
classpath.

You are looking at this wrongly[*]. The code is abominable, but might be
allowed to stay (assuming that the only alternatives are sufficiently nasty)
/IF/ the programmer can prove that there is no problematic class, /AND/ that
there never will be in the probable life of that code fragment.

I don't believe any such proof will be forthcoming, nor do I believe it would
be worth the effort of finding /and documenting/ that proof.

-- chris

([*] actually, I doubt if you are -- your instincts are sound, but you are
asking the wrong question ;-)

 

[Rogan Dawes]

You are looking at this wrongly[*]. The code is abominable, but might be
allowed to stay (assuming that the only alternatives are sufficiently nasty)
/IF/ the programmer can prove that there is no problematic class, /AND/ that
there never will be in the probable life of that code fragment.

I don't believe any such proof will be forthcoming, nor do I believe it would
be worth the effort of finding /and documenting/ that proof.

-- chris

([*] actually, I doubt if you are -- your instincts are sound, but you are
asking the wrong question ;-)

Thanks Chris. I certainly reported it as an issue, but wanted to get
some ammunition in case they argued with me ;-)

Rogan

 

[Guest]

Hi,

I was performing a security review of a web application, and encountered a
form where the class to use to format a report was specified as a form
variable.

i.e. the code was doing

Class.forName(userInput).newInstance();

Define an interface (or base class) for the user specified class.

Go ahead and run Class.forName(userInput), but store the result in a
temporary variable. I know this will cause and static blocks to execute,
but I don't know any way around this small security hole.

Check to see if the specified class implements the desired interface (or
extends the desired base class). At this point, you may (relatively)
safely instantiate the class. Assign the reference of this object to a
variable whose type is your interface or base class.

HTH,
La'ie Techie

 

[Chris Smith]

i.e. the code was doing

Class.forName(userInput).newInstance();

Can anyone think of a way that this ability could be exploited to gain
additional access to the system?

I can't think of anything terribly threatening off-hand from the
standard API. You could probably manage to listen for a network
connection by creating a UnicastRemoteObject (I haven't actually tried),
but you wouldn't be able to do anything with it.

However, Chris Uppal is entirely right. You don't just care about
what's in the standard API; you also care about any other code that
might just happen to find its way into your web application or the
Tomcat installation. Although the core API is relatively clean, I
wouldn't be surprised to find some sort of security risk in the sun.*
packages, for example. Then even if you systematically eliminated the
possibility of a risk in the standard API or accompanying classes
(something that would probably take months), you'd also have to audit
every class in your JDBC drivers, your own application, Tomcat, and any
third-party libraries you use. Then you'd need to set up a process to
audit any additional code before it is added to released versions of the
application in the future. You'd need to enforce strict standards for
the setup and configuration of the Tomcat server at every installation
of the software.

That's a lot of trouble to go through to keep one line of code.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation