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.


Mime
View raw message