--francois
On 1/5/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
As we add more security features in Derby (e.g. grant/revoke) I want to
ensure that there are no security holes.
With embedded mode the application is in the same JVM as the database
and thus can use reflection on objects returned through the JDBC api to
potentially obtain further access. A cracker's task is made somewhat
easier by the code being open source.
For example I can use reflection on a ResultSet object returned by
PreparedStatement.executeQuery () to find any additional public methods
that return objects and then use reflection on those objects/classes to
hunt for additional information. So if I can navigate to the pages in
the buffer cache then I've bypassed any grant/revoke by being able to
access the raw data directly.
This is probably less of a concern in an embedded application, where
most likely the application code is well controlled. However, in network
server mode, server side Java routines are running inside the JVM and
thus can inspect objects.
I've started looking at adding some checks for this, an inspect utility
method in the tests that perform inspection on objects and performs the
following:
- warns about public non-final fields available through the class,
this is a risk because if application code has acccess to an instance
then it can modify the field, e.g. change the conglomerate number to
access a different table.
- finds all public methods and fields on the class that return an
object and inspect those classes in the same way. The assumption is that
if a public method/field exists then there is a chance it is accessible
by application code and can be called to obtain a reference to such an
object. Note that this only follows the *declared* type of the
method/field, at runtime application cod calling the method or accessing
the field would have access to the actual implementation class and this
may expose more holes.
- warn if a non-public class can be sub-classed. Would allow access
to non-public methods by application code.
More checks can obviously be added, but I started with some easy ones.
At the moment the inspect code does not call any method on the inspected
object as it might change the state of the object, thus causing the test
to fail. Calling a method would allow it to potentially obtain more
classes to inspect in that context. It's possible that safe methods
could be called, e.g. methods to obtain Iterators over standard Java
collection objects. I'm trying to make this pass be independent of the
implementation, so that implementation changes don't break the checking.
Though a cracker, having analyzed the code, could & would make
additional calls to obtain objects.
I then add specific calls to these checks in some tests in jdbcapi, e.g.
checkDataSource is a good one as it returns Connection and Statement
objects from every way connections can be obtained.
E.g.
public void checkConnection(String dsName, Connection conn) throws
SQLException {
System.out.println("Running connection checks on " + dsName);
SecurityCheck.inspect(conn, "java.sql.Connection");
SecurityCheck.inspect(conn.getMetaData(), " java.sql.DatabaseMetaData");
A report method at the end of the test then prints any risks:
SecurityCheck.report();
Inspecting just Connection and Statement objects in this test showed
that there are public methods that potentially allow navigation to the
classes CreateConstraintConstantAction, WriteCursorConstantAction and
others! Remember, apart from the initial object this is access just
through the declared type, thus there is some chain like:
EmbedConnection -> X -> Y -> .... -> CreateConstraintConstantAction
(ie. a public method on EmbedConnection returns X, which has a public
method/field returning Y, which has a etc.)
Apart from this approach, it seems that some automated static analysis
of all classes in the embedded engine could be done. For example looking
for public/protected fields and non-interface methods in non-public classes.
Once the more obvious holes (too many public fields & methods) have been
addressed, then we could see if additional use of Java's security
features, such a s SealedObjects, are required.
Dan.
