db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (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 11:46:47 GMT

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

Knut Anders Hatlen commented on DERBY-5225:

What would a fix for this issue look like? Since this vulnerability seems to depend on the
attacker having full control over the JVM process and how it's booted, I would assume that
even if we make Derby prefer classes on derby.database.classpath to classes on the user classpath,
the attacker could just make sure the Derby version in the user classpath was one with the
old behaviour.

> 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:
>            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

View raw message