[
https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544014
]
Daniel John Debrunner commented on DERBY-3083:
----------------------------------------------
>> To my thinking increasing a security hole in any way is not a good direction
>> to go in.
> That would mean it is okay for users, who have to rename the JARs, to have no
> security at all.
Sorry, I don't follow your logic here.
> Your whole argument goes like this: Someone hacks the VM, [snip ...]
No, my argument is that there is a vulnerability, thus it is subject to be
being exploited. I'm making no arguments as to how it could be exploited, an
exploitation might require any number of other vulnerabilities in Derby, other
software or anything else. Just look at the viruses and worms that exist today,
the crackers see a useful vulnerability in one piece of code and then look for
ways to exploit it.
> injects malicious code in the right place (after the system properties from
> the command line have been overwritten by
> NetworkServerControl.installSecurityManager() and before they are used to
> install the security policy)
Note that code only needs to be run during the window of vulnerability, it does
not need to be injected into the byte code stream. Another thread running code
at the right time will do, especially on dual core machines. Even if this only
works 0.1% of the time, the potential number of derby servers available might
make it worthwhile.
[*]
If Derby wants to provide a secure database server then all such
vulnerabilities need to removed, or at the least minimized, not increased. I
see it as much like a multi-threading bug, it may look like a small window from
the code but some multi-threaded application will hit that bug.
[* "... 368,000 Microsoft SQL Server and 124,000 Oracle databases are
vulnerable to various levels of attack. [on the internet]]
[ http://www.regdeveloper.co.uk/2007/11/15/unprotected_databases_survey/ ]
> Network server demands a file called "derbynet.jar" in classpath
> ----------------------------------------------------------------
>
> Key: DERBY-3083
> URL: https://issues.apache.org/jira/browse/DERBY-3083
> Project: Derby
> Issue Type: Bug
> Components: Tools
> Affects Versions: 10.3.1.4
> Reporter: Aaron Digulla
> Attachments: derby-3083-01-requireDerbynet-aa.diff,
> derby-716-10-datatypesCollation-aa.diff
>
>
> The network server will not start if the derbynet jar is added under a
> different name than "derbynet.jar" to the classpath. This makes it impossible
> to use it in maven projects where the jar is renamed to
> "derbynet-10.3.1.4.jar".
> This did work with 10.2.2.0
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
