Derby's class loading order can be used to subvert the security of user-defined
routines and even to corrupt data
-----------------------------------------------------------------------------------------------------------------
Key: DERBY-5225
URL: https://issues.apache.org/jira/browse/DERBY-5225
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.9.0.0
Reporter: Rick Hillegas
Several Derby behaviors are vulnerable to the fact that in an embedded
application, you can override the database-specific classpath with classes that
appear in the user classpath (the classpath specified on the VM boot command).
By putting your malicious code on the VM classpath, your overrides of
procedures and functions will run instead of the versions stored inside jar
files in the database (the ones wired into derby.database.classpath). This
behavior of derby.database.classpath is described here:
http://db.apache.org/derby/docs/10.8/devguide/devguide-single.html#cdevdeploy30736
Vulnerable behaviors include:
1) DBO-owned routines which run with definer's rights. If you override one of
these procedures, you can run any code you want with the privileges of the DBO.
2) CHECK constraints. If a CHECK constraint invokes a user-defined function,
you can override the function and subvert the intention of the constraint.
3) Generated columns. If a generated column invokes a user-defined function,
you can subvert the value that is generated.
All of these cases can give rise to data which does not conform to the
application designer's consistency rules. That is, corrupt data.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
