db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3083) Network server demands a file called "derbynet.jar" in classpath
Date Wed, 21 Nov 2007 17:01:00 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544526

Daniel John Debrunner commented on DERBY-3083:

> So Daniel's arguments boils down to this: "I enhance security by enforcing the JAR to
have a certain name/path".
That is my argument yes.

> As long as I can add malicious code to the JAR without the SM noticing, enforcing the
name will not give additional protection.
Agreed, it gives no additional protection for that specific situation, I have not claimed
it would do. Remember I'm making no assumptions about how a vulnerability is exploited, only
that it is there to be exploited. Thus I'm not making assumptions the attacker has access
to the a local machine or ability to modify the jars etc.

The policy file that allows an arbitrary name for the code source has the potential for it
to be applied to any jar on the file system, a policy file with a specific name portion (such
as derby.jar) can only be applied to a limited number of jars on the file system. The policy
file in question has some very useful permissions, such as ALL FILES.

> Therefore, enforcing a specific name will only add a false sense of security which isn't
really there. 
I've only ever claimed that the specific names reduces a vulnerability.

> 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 and one I would not be willing to make when looking
at security. Remember the vulnerability exists before the security manager is installed, thus
setting system properties is open for any code running in the jvm. Could some JMX agent or
debugging agent be active that would allow properties to be set from a remote user (or local
user using tcp/ip)?.

> SM doesn't give any protection against a local attacker anyway
One does have to be concerned about local attackers, while a local attacker may have access
to the machine (be logged on, able to run processes on the machine), they may not have access
to your files, thus there may be incentive for them to exploit vulnerabilities to read/modify
your data.

> This will be as safe as the static JAR names (as to my argument above) and it will work
for both the case that the JARs have been renamed and that they have been collected in an
> If they embed the code in a larger app, they have to think about security themselves;
we aren't able to forsee what they might do and therefore, we can't make their code secure
for them at this time.

These two statements contradict each other, the first says Derby should install a security
manager using whatever jar file the code is in, hence giving the impression Derby is making
the system secure for them. The second says (correctly) we can't make their code secure for
them in this situation.

I'm not sure what Aaron & Rick are really arguing, it's either there is no vulnerability
or there is a vulnerability but there's no/little chance of it being exploited.
I think that any security breach is usually made up of a number of  vulnerabilities, not a
single point of failure.

> 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:
>            Reporter: Aaron Digulla
>         Attachments: derby-3083-01-requireDerbynet-aa.diff, derby-3083-01-requireDerbynet-ab.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-".
> This did work with

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

View raw message