[
https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546305
]
Daniel John Debrunner commented on DERBY-3083:
----------------------------------------------
>>> storing these URLs in the system properties (or any global variable) is
>>> okay too, because this cannot be exploited from a remote attacker
>>That's an assumption that's hard to prove
> This is very easy to prove: At the time this happens, the Network Server code
> has not yet created a socket, so a remote attacker can't connect -> q.e.d.
I don't think it's that easy. What other code could be running, could the JVM
have JMX active allowing other code, could some debugging api be active, is the
network server running in another framework such as tomcat?
> My argument is that there is no additional vulnerability if you allow any JAR
> name, it just makes an existing vulnerability more visible [snip]. This
> existing vulnerability can't be closed by enforcing a specific JAR name,
I agree, but as you say allowing any jar name "makes an existing vulnerability
more visible", thus increasing the potential for the vulnerability to be
exploited. I don't think that's a good direction for a security conscious
product to go in.
>> These two statements contradict each other,...
> I'm talking about two completely different things here: One talks about
> taking the code from the Derby project unmodified and the other talks about a
> developer building their own Derby server.
But to the Derby network code those two situations look the same, it's derby
code running in a jar, thus it seems in the unmodified or uberjar cases you
want Derby to install a security manager, but in the modified code case you
don't?
> 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-3083-01-requireDerbynet-ab.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.
