db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5225) Derby's class loading order can be used to subvert the security of user-defined routines and even to corrupt data
Date Thu, 12 May 2011 12:21:47 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032372#comment-13032372
] 

Rick Hillegas commented on DERBY-5225:
--------------------------------------

Right. We could tie the fix to a certain rev level of the data (say 10.9). That would prevent
black hats from subverting the fix by using 10.8 out-of-the-box. However, a black hat could
hack a version of 10.9 to ignore the fix.  Other vulnerabilities would be possible for someone
with those skills, including bypassing authorization checks altogether.

> 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

Mime
View raw message