db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2133) Detect tampering of installed jar files in an encrypted database
Date Tue, 30 Jun 2009 14:47:47 GMT

     [ https://issues.apache.org/jira/browse/DERBY-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Dag H. Wanvik updated DERBY-2133:

    Component/s: Miscellaneous

> Detect tampering of installed jar files in an encrypted database
> ----------------------------------------------------------------
>                 Key: DERBY-2133
>                 URL: https://issues.apache.org/jira/browse/DERBY-2133
>             Project: Derby
>          Issue Type: Improvement
>          Components: Miscellaneous
>            Reporter: Daniel John Debrunner
> Since the jar files (from sqlj.install_jar) are stored unencrypted in an encrypted database
a secuirty hole exists where the jar can be replaced by malicious code.
> One way to detect this would be to store an MD5 checksum of the jar's contents in the
SYSFILES table (as a new column) and to match this checksum with the jar file when opening
it. This only makes sense for encrypted databases, as if a cracker can hack the jar file in
an unencrypted database they can also fix up the checksum. Also adding this checksum on a
unencrypted database would require some alternate scheme for J2ME/CDC/Foundation which (I
think) does not support MD5 checksums.
> th eother option of encrypting the jar seems less appealing as it will increase the complexity
of loading classes and move away from using the standard URLClassLoader.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message