Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What is the security risk of object reflection?

Tags:

So after a few hours of workaround the limitation of Reflection being currently disabled on the Google App Engine, I was wondering if someone could help me understand why object reflection can be a threat. Is it because I can inspect the private variables of a class or are there any other deeper reasons?

like image 510
Legend Avatar asked Jun 09 '10 03:06

Legend


People also ask

Is Java reflection a security risk?

This vulnerability is caused by unsafe use of the reflection mechanisms in programming languages like Java or C#. An attacker may be able to create unexpected control flow paths through the application, potentially bypassing security checks. Exploitation of this weakness can result in a limited form of code injection.

Is it good to use reflection in Java?

Java Reflection is quite powerful and can be very useful. Java Reflection makes it possible to inspect classes, interfaces, fields and methods at runtime, without knowing the names of the classes, methods etc. at compile time.

Why not use reflection in Java?

Harder Code Comprehension In the same way that Reflection makes it harder for automated tools to understand code, it also makes it harder for humans to understand code. Reflection introduces surprises.

What is reflection C#?

Reflection provides objects (of type Type) that describe assemblies, modules, and types. You can use reflection to dynamically create an instance of a type, bind the type to an existing object, or get the type from an existing object and invoke its methods or access its fields and properties.


2 Answers

1 - Reflection (as a concept) is indeed orthogonal to safety/security.

There was a big emphasis in the design of java to make it a safe platform, with static typing, security manager, disciplined usage of class loader, and no way to screw pointers/memory. You can read the interview of James Gosling in Masterminds of programming, which is interesting about that.

But the more reflective power you have the harder it is to ensure things are safe as they should. Reflection defeat notably static typing and can lead to run-time errors.

But more subtle things can happen as well. For instance class loaders -- which can be considered as reflective hook in the system -- were not designed properly in the early version of Java leading to potential type replacement. The article Dynamic class loading in the JVM, by Gilad Bracha, is insightful on such issues.

Reflection can not be turned off altogether; it's always possible to reflect on its own public fields/methods. Reflection on private structures with AccessibleObject.setAccessible can however be disabled, because it breaks encapsulation. With access to private fields, etc. inspection and modification of internal data is possible. It can lead to various malicious exploits, e.g.

  • strings are not immutable anymore and can be changed (see this question)
  • you can reveal sensible information of objects you don't own
  • ... other exploits ...

Finally there are other mechanism that put security in jeopardy, notably sun.misc.Unsafe which gives direct access to the memory -- pointers are back.

2 - Now, the question is whether reflection (in practice) leads to that many risks.

I've read the link pointed by @dbyrne but it's mostly about .net. Also I don't know exactly what is disabled for Google App. Is it the ReflectPermission only, or other permission of the security manager? One danger is clearly to get access to the file system and mess around.

The problem of access to private data and breaking encapsulation can be argued in practice. Writing secure code is indeed extremely hard, and even without changing the access modifier you can subclass classes in an inappropriate way -- unless they are final, or even better, sealed -- and pass them around. This is for instance what defensive copying try to protect against.

Type-safety is also anyway threatened by run-time error because of downcast, so this point can also be argued.

In a shared/hosted environment, the security is relative. At the language level, you can for instance not prevent a module form consuming 100% of CPU or consuming all memory up to a OutOfMemoryException. Such concerns need to be addressed by other means, typically at the OS level, with virtualization and quotas.

So my personal answer, would be: reflection is a security risk, but not that big in practice if compared to other potential attack vectors.

like image 199
ewernli Avatar answered Sep 29 '22 23:09

ewernli


An application can use the Java reflection APIs to access and update fields, and execute methods that are forbidden by normal Java access / visibility rules. With a bit of ingenuity, this is sufficient to:

  • access information that is supposed to be hidden,
  • subvert the Java security sandbox so that you can interfere with other things running in the JVM, access files on the local machine, and so on.

Under certain circumstances, it might even allow the injection of malicious native code.

like image 31
Stephen C Avatar answered Sep 30 '22 01:09

Stephen C