You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Daniel John Debrunner <dj...@apache.org> on 2006/01/05 18:24:21 UTC
Application code inspecting Derby's embedded objects
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.
Re: Application code inspecting Derby's embedded objects
Posted by Francois Orsini <fr...@gmail.com>.
Very useful checks for sure - This is not related (different itch) but since
you've mentioned Grant&Revoke I tought I might add the following as another
security issue - Until Derby has got support for "system privileges", a
successfully authenticated user to a Derby system or database is able to
shutdown particular database(s) or a whole derby instance - luckily Derby
does not have a DROP DATABASE command which is another system privilege ;).
--francois
On 1/5/06, Daniel John Debrunner <dj...@apache.org> 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.
>
>
>
>
Re: Application code inspecting Derby's embedded objects
Posted by Jeffrey Lichtman <sw...@rcn.com>.
>As a related itch, we might want to give some thought to tools for
>tracking and sealing off security breaches. For instance, audit
>trails and tools to deny access to malicious users and clients.
>
>-Rick
Good idea. One possible tool could be a class/method inspector that
would look for risky code (like reflection) and either prevent the
user from calling it or audit the fact that it was called.
- Jeff Lichtman
swazoo@rcn.com
Check out Swazoo Koolak's Web Jukebox at
http://swazoo.com/
Re: Application code inspecting Derby's embedded objects
Posted by Rick Hillegas <Ri...@Sun.COM>.
Plugging security holes is a worthy, ongoing project. As a related itch,
we might want to give some thought to tools for tracking and sealing off
security breaches. For instance, audit trails and tools to deny access
to malicious users and clients.
Regards,
-Rick
Re: Application code inspecting Derby's embedded objects
Posted by Øystein Grøvlen <Oy...@Sun.COM>.
>>>>> "DJD" == Daniel John Debrunner <dj...@apache.org> writes:
DJD> Apart from this approach, it seems that some automated static
DJD> analysis of all classes in the embedded engine could be
DJD> done. For example looking for public/protected fields and
DJD> non-interface methods in non-public classes.
I think it also would be useful to get a list of all public/protected
methods that are only used within the same package. Many of them
could probably be made package private.
--
Øystein
Re: Application code inspecting Derby's embedded objects
Posted by Daniel John Debrunner <dj...@apache.org>.
Øystein Grøvlen wrote:
>>>>>>"SB" == Satheesh Bandaram <sa...@Sourcery.Org> writes:
>
>
> SB> Now I understand what you mean by this... after reading
> SB> Oystein's question. Current proposal only has EXECUTE
> SB> privilege to allow executing procedures and functions. Creator
> SB> of the routine can define if that needs to be executed as the
> SB> invoker or the definer.
>
> I think restricting the privilege to create stored procedures are a
> much more effective way of prohibiting stored procedures with
> malicious code than any attempt to limit access to the internal data
> structure of a Derby class.
True, but as with any system security is a result of a number of
restrictions, not a single one. Even with correct authentication and
authorization set up, my itch is to ensure:
- allowing third-party server-side code within Derby should be an
understandble risk to the database owner.
- allowing a third party Derby based application on a machine should
should be an understandble risk to the system owner.
Dan.
Re: Application code inspecting Derby's embedded objects
Posted by Øystein Grøvlen <Oy...@Sun.COM>.
>>>>> "SB" == Satheesh Bandaram <sa...@Sourcery.Org> writes:
SB> Now I understand what you mean by this... after reading
SB> Oystein's question. Current proposal only has EXECUTE
SB> privilege to allow executing procedures and functions. Creator
SB> of the routine can define if that needs to be executed as the
SB> invoker or the definer.
I think restricting the privilege to create stored procedures are a
much more effective way of prohibiting stored procedures with
malicious code than any attempt to limit access to the internal data
structure of a Derby class.
--
Øystein
Re: Application code inspecting Derby's embedded objects
Posted by Francois Orsini <fr...@gmail.com>.
Roles ease the management of group privileges - these privileges can be
system or/and object ones.
The concept of system and object privileges is explained here quite well:
http://www.samspublishing.com/library/content.asp?b=STY_Sql_24hours&seqNum=154&rl=1
Hope this helps,
--francois
On 1/6/06, Satheesh Bandaram <sa...@sourcery.org> wrote:
>
> I am not familiar with this terminology, I think. I would like to see what
> you mean by this... Do you mean roles?
>
> Satheesh
>
> Francois Orsini wrote:
>
> There is no support for "create privileges" (which are part of "system"
> ones) currently in the phase I of grant/revoke - Am looking at system
> prvileges to support for Derby at a minimum and will be posting something
> soon. Phase I deals with object privileges at the moment.
>
> --francois
>
> On 1/6/06, Øystein Grøvlen <Oy...@sun.com> wrote:
> >
> > >>>>> "RH" == Rick Hillegas <Ri...@Sun.COM> writes:
> >
> > RH> These are useful checks. It reminds me of how vulnerable we are
> > given
> > RH> all the ways that users can inject code into the database. A
> > malicious
> > RH> or buggy function/procedure/aggregate/adt/vti could
> > probably find a
> > RH> way to mount a denial of service attack. Our user documentation
> > should
> > RH> point out the importance of tightly
> > restricting who can inject
> > RH> code. As you note, GRANT/REVOKE will be our first line of
> > defense.
> >
> > Does the current GRANT/REVOKE work include a specific privilege for
> > creating stored procedures?
> >
> > --
> > Øystein
> >
> >
>
Re: Application code inspecting Derby's embedded objects
Posted by Francois Orsini <fr...@gmail.com>.
There is no support for "create privileges" (which are part of "system"
ones) currently in the phase I of grant/revoke - Am looking at system
prvileges to support for Derby at a minimum and will be posting something
soon. Phase I deals with object privileges at the moment.
--francois
On 1/6/06, Øystein Grøvlen <Oy...@sun.com> wrote:
>
> >>>>> "RH" == Rick Hillegas <Ri...@Sun.COM> writes:
>
> RH> These are useful checks. It reminds me of how vulnerable we are
> given
> RH> all the ways that users can inject code into the database. A
> malicious
> RH> or buggy function/procedure/aggregate/adt/vti could
> probably find a
> RH> way to mount a denial of service attack. Our user documentation
> should
> RH> point out the importance of tightly
> restricting who can inject
> RH> code. As you note, GRANT/REVOKE will be our first line of defense.
>
> Does the current GRANT/REVOKE work include a specific privilege for
> creating stored procedures?
>
> --
> Øystein
>
>
Re: Application code inspecting Derby's embedded objects
Posted by Øystein Grøvlen <Oy...@Sun.COM>.
>>>>> "RH" == Rick Hillegas <Ri...@Sun.COM> writes:
RH> These are useful checks. It reminds me of how vulnerable we are given
RH> all the ways that users can inject code into the database. A malicious
RH> or buggy function/procedure/aggregate/adt/vti could probably find a
RH> way to mount a denial of service attack. Our user documentation should
RH> point out the importance of tightly restricting who can inject
RH> code. As you note, GRANT/REVOKE will be our first line of defense.
Does the current GRANT/REVOKE work include a specific privilege for
creating stored procedures?
--
Øystein
Re: Application code inspecting Derby's embedded objects
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> These are useful checks. It reminds me of how vulnerable we are given
> all the ways that users can inject code into the database. A malicious
> or buggy function/procedure/aggregate/adt/vti could probably find a way
> to mount a denial of service attack. Our user documentation should point
> out the importance of tightly restricting who can inject code. As you
> note, GRANT/REVOKE will be our first line of defense.
Denial of service attacks will be the hardest to prevent, some are easy
to prevent, such as the routine calling System.exit. Others such as
eating up runtime resources (cpu time & memory), or throwing a
java.lang.VirtualMachineError exception are harder to prevent.
Dan.
Re: Application code inspecting Derby's embedded objects
Posted by Rick Hillegas <Ri...@Sun.COM>.
These are useful checks. It reminds me of how vulnerable we are given
all the ways that users can inject code into the database. A malicious
or buggy function/procedure/aggregate/adt/vti could probably find a way
to mount a denial of service attack. Our user documentation should point
out the importance of tightly restricting who can inject code. As you
note, GRANT/REVOKE will be our first line of defense.
Regards,
-Rick
Daniel John Debrunner 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.
>
>
>
>
>