You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Aaron Digulla (JIRA)" <ji...@apache.org> on 2007/09/19 11:03:43 UTC
[jira] Created: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
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
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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533750 ]
Rick Hillegas commented on DERBY-3083:
--------------------------------------
On derby-dev, Bryan suggests another solution:
Alternatively, perhaps we could have a glance at the classpath
during startup, perhaps by sharing the code that sysinfo uses,
and only install the default policy if the user appears to
be using the default set of jars.
That is, if we don't see derby.jar, derbynet.jar on the
classpath when starting up Network Server, then we assume that
the user has taken control of the *entire* configuration process,
including the configuration of the security policy, and so we
don't attempt to install a default security policy in that case.
> 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
>
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533552 ]
Daniel John Debrunner commented on DERBY-3083:
----------------------------------------------
The derby jars contain metadata (including [but not limited to] a security policy) that assumes the names of the jars and that they reside in the same folder.
Does any documentation indicates that it's ok to change the jar names and have everything continue to work as before?
> 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
>
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544514 ]
Rick Hillegas commented on DERBY-3083:
--------------------------------------
Ported 597125 from trunk to 10.3 branch at subversion revision 597131.
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-3083:
----------------------------------
Issue & fix info: [High Value Fix, Repro attached] (was: [High Value Fix])
Urgency: Normal
Triaged for 10.5.2. Set Normal urgnecy. Since you can't start network server with the jar file names as we post them to maven and since this is a regression, we might consider making this urgent for the next release.
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540568 ]
Rick Hillegas commented on DERBY-3083:
--------------------------------------
I think I like Bryan's approach best. If we don't see derby.jar and derbynet.jar on the classpath, then we won't install a security manager. Unless someone objects strongly, I will code this fix. Thanks.
> 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-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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Aaron Digulla (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533642 ]
Aaron Digulla commented on DERBY-3083:
--------------------------------------
Does any documentation indicate that it's *not* ok to change the JAR name? :-) This is Java after all and I'm used that I can use what I can put on the classpath. Moreover, when you use Maven, then the JAR names must include the version number. So this change makes it impossible to use Derby with Maven.
I'm using Derby extensively to replace a real DB2 for my test cases and I couldn't care less about a security policy. It's nice to have one shipped with the product but I fail to see the advantage to make it the *default*.
> 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
>
> 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.
[jira] Updated: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-3083:
----------------------------------
Derby Categories: [High Value Fix]
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544508 ]
Rick Hillegas commented on DERBY-3083:
--------------------------------------
Committed derby-3083-01-requireDerbynet-ab.diff at subversion revision 597125. I believe that this fixes the regression introduced by DERBY-2196. However, the discussion of this issue is continuing.
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543628 ]
Rick Hillegas commented on DERBY-3083:
--------------------------------------
Right now the default policy file grants permissions to the following codebases:
${derby.install.url}derby.jar
${derby.install.url}derbynet.jar
${derby.install.url}derbytools.jar
${derby.install.url}derbyclient.jar
${derby.install.url}derbytesting.jar
At boot time, the server sets the value of the derby.install.url property before installing a SecurityManager. We could refine our codebase declarations to something like this:
${derby.install.derby.jar.url}
${derby.install.derbynet.url}
${derby.install.derbytools.url}
${derby.install.derbyclient.url}
${derby.install.derbytesting.url}
Then the server could set the values of these properties using a heuristic like this:
${derby.install.derby.jar.url} - the jar where EmbeddedDriver lives
${derby.install.derbynet.url} - the jar where NetworkServerControl lives
${derby.install.derbytools.url} - the jar where ij lives
${derby.install.derbyclient.url} - the jar where ClientDriver lives
${derby.install.derbytesting.url} - the jar where BaseTestCase lives
For extra credit, we could use this strategy to clean up the multiple permission grants needed to handle sysinfo. That is, the policy file could grant those permissions to one code base:
${derby.install.sysinfo.jar.url} - the first jar where sysinfo lives
Does this sound like an acceptable solution?
> 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-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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543686 ]
Daniel John Debrunner commented on DERBY-3083:
----------------------------------------------
> I don't understand how the property setting could be intercepted. That would involve injecting malicious code into NetworkServerControl.installSecurityManager()
> just after the properties are forcibly set and just before the SecurityManager is installed.
Correct.
> These are properties which are private to Derby and which we don't allow the user to override.
How are system properties private to Derby and what stops a user overriding them?
> Could you explain more about how the property setting could be intercepted?
There is a window as you describe where other code could manipulate the property values. Currently any code that does manage to execute during that window has a limited range of changes it can make with respect to the default policy file. Today it can get the permissions granted to the derby files to be granted to other files with identical names. Making the complete jar name in the policy file a property expands the scope of malicious activity, now the code could give permissions to any jar.
As for how, well I think you are looking at the approach of proving such an interception can not happen, I don't know how to do that.
I'm looking at the approach of there is a window for such intrusion, so it's bound to be exploitable by someone (e.g. JMX?), so given it can happen what can be done to minimize or even remove any malicious attacks.
Trying to prove something can't happen seems much harder to me than minimizing the effects of when it does happen.
Fixing DERBY-2362 would help in this area, ensuring the the security manager installed is the one the network server code configured.
> 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-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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544019 ]
Daniel John Debrunner commented on DERBY-3083:
----------------------------------------------
In the patch isn't the string manipulation in packagingLooksGood just implementing String.endsWith()?
It would be good for the comments to packagingLooksGood() explicitly state what the expected packaging is.
Any reason why for Maven'ized jars we can't support the jar file name matching the version number:
Something like
${derby.install.url}derbynet${derby.version}.jar
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Aaron Digulla (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529028 ]
Aaron Digulla commented on DERBY-3083:
--------------------------------------
Thanks for the workaround. -noSecurityManager works for me, too.
In that case, the security manager should be fixed not to rely on a fix jar name :-) What happens when I patch the JAR or feed Java a completely different JAR as "derbynet.jar"?
> 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
>
> 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.
[jira] Updated: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik updated DERBY-3083:
---------------------------------
Issue & fix info: [High Value Fix]
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Aaron Digulla (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540856 ]
Aaron Digulla commented on DERBY-3083:
--------------------------------------
Well, I've used tons of Java software (probably everything kind except for applets) and Derby was the first one to have a Security Manager, so in my case running into one violated the rule "least surprises". OTOH, I know perfectly well that a misconfigured network server compromises the security of my computer (they all do, that's common knowledge even if most people actively ignore this simple fact). Therefore, a network server which is secure also violates the rule.
So it is an attempt to make the world better on your part but it certainly breaks the "least surprise" rule unless you can make it work even when I do strange things like renaming the JAR, repackaging everything in an ueberjar and the like. If you really, absolutely need to have your SM, make it fail gracefully (if DerbyNet can't install it, print a warning and go on) or ask the user to enable it with an option if they need/want it.
Otherwise, you will annoy 90% of the users of your code:
10% know more about security than you do and they do it differently; trying to teach them won't work
80% don't know and don't care and they hate you for making their lives "unnecessary" complex (a.k.a "what do I need that stupid virus scanner for? Open that proxy already! OWN3Z.COM wants to install TakeOver.EXE? OK!")
Which leaves 10% who don't know and care enough to learn how to secure their system
;-)
I'm in the first 10%, by the way: For my JUnit tests, I just need an option to bind the server to 127.0.0.1 and no SM.
> 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-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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546770 ]
Knut Anders Hatlen commented on DERBY-3083:
-------------------------------------------
Is there any reason why we don't implement our own SecurityManager with hard-coded default permissions? Then we could just pass in the jar names to its constructor instead of relying on the system properties.
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528951 ]
Kathey Marsden commented on DERBY-3083:
---------------------------------------
I have not confirmed but think this may be related to DERBY-2196 to install a security manager by default. I notice it does not display when I start with -noSecurityManager. A possible workaround may be to install your own security manager instead of using the default one.
> 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
>
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Aaron Digulla (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544794 ]
Aaron Digulla 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.
> 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.
My argument is that there is no additional vulnerability if you allow any JAR name, it just makes an existing vulnerability more visible (so people who are concerned will know about it and can plan against it). This existing vulnerability can't be closed by enforcing a specific JAR name, so it doesn't matter what the name is and where it comes from.
So far, you have failed to come up with a convincing argument why my argument is wrong. If you insist that there might be additional vulnerabilities, list them one by one. Talking "grand" when we try to find a way to patch a bug is not helping. At the end of the day, the software must work and it must be as secure as we can make it; no more and no less.
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Aaron Digulla (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540712 ]
Aaron Digulla commented on DERBY-3083:
--------------------------------------
Rick: This again breaks the idea of "least surprise". The network server should not try to install a security manager at all until told so. The first breaking of that rule is what caused the problems in the first place.
I suggest that you remove the code which tries to install the SM by default and add new code which is enabled by an option (property or command line). That option should either be "yes/no" if you can figure out the name of the JAR or it should specify the name of the JAR which contains the preferred SM. If the option is given and no SM can be installed, an exception should be thrown, aborting the program.
This would give control to the user instead of involving further black magic which will only lead to a long series of bugs and patches, all because of breaking "least surprise" again and again.
> 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-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.
[jira] Updated: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel John Debrunner updated DERBY-3083:
-----------------------------------------
Comment: was deleted
> 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-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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543900 ]
Rick Hillegas commented on DERBY-3083:
--------------------------------------
>The fix is described in the description to DERBY-2362, I don't see any windows of vulnerability, could you explain what you are thinking?
We seem to be talking about an attacker who has the ability to change system properties at any point in Derby's processing. Here is the scenario which came to my mind:
1) Derby sets system properties just before installing a security manager.
2) Blackhat changes the properties.
3) Derby installs the security manager.
4) Blackhat prompts a call to the security manager, which faults in the policy file and substitutes in the current values of the system properties.
5) Blackhat then changes the properties back to the values which Derby set.
6) Derby then runs the checks described in DERBY-2362 but sees nothing amiss.
> 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-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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529492 ]
Kathey Marsden commented on DERBY-3083:
---------------------------------------
Aaron said:
>In that case, the security manager should be fixed not to rely on a fix jar name :-) What happens when I >patch the JAR or feed Java a completely different JAR as "derbynet.jar"?
I agree. perhaps Rick has some ideas on how to achieve this since he implemented the functionality For the sake of backward compatibility I think at least the start should not fail and perhaps just print a warning to derby.log that the security manager was not installed.
> 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
>
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533799 ]
Daniel John Debrunner commented on DERBY-3083:
----------------------------------------------
Aaron> Does any documentation indicate that it's *not* ok to change the JAR name? :-)
Well the documentation describes what the code does, if someone changes something you can't necessarily assume that the code will work the same way :-)
It's much like if someone decided to put all the locale messages into a single locale jar and removed the others, Derby using the documented code path will then not pick up any localized messages because the change is incomplete.
> 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-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.
[jira] Updated: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel John Debrunner updated DERBY-3083:
-----------------------------------------
Comment: was deleted
> 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-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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540588 ]
Daniel John Debrunner commented on DERBY-3083:
----------------------------------------------
Rather than checking the classpath (which is non-standard) and needs to be more detailed(*) than derby.jar and derbynet.jar on the classpath, why not simply see the name of the jar the network server code is coming from. The code must already get the url to set up the properties for the server policy.
(*) Classpath could just be derbynet.jar, could be started using -jar command with derbyrun.jar or derbynet.jar, ...
> 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-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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547044 ]
Knut Anders Hatlen commented on DERBY-3083:
-------------------------------------------
Hi Rick, I agree that extending Policy sounds less complicated. If we do that, it would be OK to grant permissions to the jar files containing Derby code regardless of their name, wouldn't it? The only concern I can think of is that someone could fake the return value from getProtectionDomain(), but if someone has managed to get control over your JDK libraries, it's game over anyway.
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Aaron Digulla (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543832 ]
Aaron Digulla 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.
Your whole argument goes like this: Someone hacks the VM, intercepts the bytecode executor or the JIT, 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) and thus takes over the network manager. A possible scenario, I admit. Anyone here who believes this will ever happen?
If I gain access to the VM, it would be much more simple to use the debug API to replace the class implementing the SecurityManager or to patch the JARs and restart the service.
So ... yes, Ricks approach widens the security window but I fail to see it creating a wider attack vector than what we already have. If you have access to the VM, then you can whack this security scheme to death but my understanding of the whole secuity manager in the Derby context is to make sure it is not possible to inject malicious code from the network side. At the time when the SM is installed, Derby doesn't accept connections, so there is no attack vector at this time.
After that, the SM is installed and malicious code from outside is confined within the limits of the SM.
If someone has access to the machine, no SM in the world can prevent them to play with the JARs, the classpath or the VM. That is host security and completely outside the scope of Derby.
> 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-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.
[jira] Updated: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-3083:
---------------------------------
Attachment: derby-716-10-datatypesCollation-aa.diff
Attaching derby-716-10-datatypesCollation-aa.diff. This adds tests verifying the following:
1) Make sure that Derby calls the expected getXXX() method for each legal datatype in the rowset returned by a table function.
2) Make sure that string columns in the returned rowset have the expected collation (described in the previous comment).
The second test uncovered a bug: we were always applying BASIC collation to string columns in the returned rowsets. This patch fixes that bug.
Touches the following files:
M java/engine/org/apache/derby/impl/sql/compile/CreateAliasNode.java
M java/engine/org/apache/derby/catalog/types/TypeDescriptorImpl.java
Fix for the collation bug.
M java/testing/org/apache/derbyTesting/functionTests/tests/lang/TableFunctionTest.java
M java/testing/org/apache/derbyTesting/functionTests/tests/lang/StringArrayVTI.java
New tests.
> 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-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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546781 ]
Rick Hillegas commented on DERBY-3083:
--------------------------------------
Thanks for that suggestion, Knut. I have been thinking along similar lines. We could extend SecurityManager with our own implementation. Alternatively, we could extend Policy with our own policy object and continue to use the default SecurityManager. At first blush, the latter looks less complicated to me.
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543730 ]
Daniel John Debrunner commented on DERBY-3083:
----------------------------------------------
> By "private to Derby" I mean that the properties cannot be overridden by any scheme that I'm aware of.
But any code that could execute in the window described previously could change those properties, thus they are not private to derby since they are system properties.
> Fixing DERBY-2362 could reduce the vulnerability. However, I don't understand how to fix DERBY-2362. The solutions which come to my mind seem to have the same small windows of vulnerability
The fix is described in the description to DERBY-2362, I don't see any windows of vulnerability, could you explain what you are thinking?
> As you note, if there is a way to exploit this window, then it can be used to subvert the value of "derby.install.url" today. The incremental exposure seems very small to me.
To my thinking increasing a security hole in any way is not a good direction to go in.
> 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-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.
[jira] Updated: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren updated DERBY-3083:
--------------------------------------
Derby Info: [Regression] (was: [Patch Available, Regression])
I'm removing patch available flag; it appears from the discussions the patch wasn't fully approved.
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533771 ]
Rick Hillegas commented on DERBY-3083:
--------------------------------------
Never mind the previous attachment and comment. I have attached this patch to the wrong issue.
> 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-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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Aaron Digulla (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544392 ]
Aaron Digulla commented on DERBY-3083:
--------------------------------------
> No, my argument is that there is a vulnerability, thus it is subject to be being exploited.
Okay, let me see if we're on the same track here: A Security Manager will do this: It will enforce allowed operations on specific JARs on the classpath. The JARs are not signed and not protected in any way other than their name and path.
So Daniel's arguments boils down to this: "I enhance security by enforcing the JAR to have a certain name/path". I do not believe this is true. As long as I can add malicious code to the JAR without the SM noticing, enforcing the name will not give additional protection. Therefore, enforcing a specific name will only add a false sense of security which isn't really there. This is even more dangerous than having an unknown vulnerability since people will believe they are safe when they are not.
To be as safe as we can possibly be, I suggest that you use Class.getResource() on specific classes which should be on the classpath and strip the package and class from the resulting URL. 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 ueberjar.
For the same reasons, storing these URLs in the system properties (or any global variable) is okay too, because this cannot be exploited from a remote attacker and the SM doesn't give any protection against a local attacker anyway. As long as users use the supplied code, they will be perfectly safe as long as no one can modify the classpath when the server is started. 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.
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540871 ]
Daniel John Debrunner commented on DERBY-3083:
----------------------------------------------
To be clear the security manager is trying to secure the out of the box configuration, not a misconfigured server.
Is it typically for a database server in its out of the box configuration to allow any remote user to take over a machine?
> 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-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.
Re: [jira] Commented: (DERBY-3083) Network server demands a file
called "derbynet.jar" in classpath
Posted by Bryan Pendleton <bp...@amberpoint.com>.
> I imagine that we could parameterize the names of the jars
> in the default policy and then teach server startup to make
> some smart guesses about which jars are germane, based on
> whether they contain certain distinguished classes.
Alternatively, perhaps we could have a glance at the classpath
during startup, perhaps by sharing the code that sysinfo uses,
and only install the default policy if the user appears to
be using the default set of jars.
That is, if we don't see derby.jar, derbynet.jar on the
classpath when starting up Network Server, then we assume that
the user has taken control of the *entire* configuration process,
including the configuration of the security policy, and so we
don't attempt to install a default security policy in that case.
thanks,
bryan
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533728 ]
Rick Hillegas commented on DERBY-3083:
--------------------------------------
I imagine that we could parameterize the names of the jars in the default policy and then teach server startup to make some smart guesses about which jars are germane, based on whether they contain certain distinguished classes.
Technically, there's nothing to prevent users from breaking open all of Derby's jar files and recombining them into a single giant jar. I think that if a user does that, then the user is responsible for adjusting the security policy.
If Maven is going to rename jar files, then I think Maven needs to regenerate the security policy. This is just how Java security works: permissions are granted to named code domains and those domains are identified by jar file names.
Aaron is right that we haven't stated explicitly what kinds of tampering void your warranty. Perhaps we should add a big warning in our user guides.
> 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
>
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547151 ]
Rick Hillegas commented on DERBY-3083:
--------------------------------------
Hi Knut. I agree that if someone has subverted getProtectionDomain(), then the fox is already in the hen house. I think this could be our sequence of operations:
1) Determine the protection domains (e.g. jar files) which will receive privileges.
2) Construct a DerbyPolicy from those protection domains.
3) Install the default SecurityManager with a dummy policy which lets us change policies immediately afterwards
4) Install the DerbyPolicy (Policy.setPolicy( derbyPolicy ) )
If there is a window of vulnerability, then I sense that it would lie between steps (3) and (4). However, I don't see a vulnerability right now.
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543645 ]
Rick Hillegas commented on DERBY-3083:
--------------------------------------
Thanks for the quick feedback, Dan.
The server policy file grants permissions to derbytools, derbyclient, and derbyTesting in order to fix DERBY-3086. The problem is that we don't control the order in which jar files are wired into the classpath. Unfortunately, sysinfo lives in all of those jar files and the permissions it needs must be granted to the first of those jar files which appears on the classpath.
I don't understand how the property setting could be intercepted. That would involve injecting malicious code into NetworkServerControl.installSecurityManager() just after the properties are forcibly set and just before the SecurityManager is installed. These are properties which are private to Derby and which we don't allow the user to override. Could you explain more about how the property setting could be intercepted?
The security hole I see is if the customer repackages the jar files, perhaps folding them into a master jar file which contains application code. In that case the proposed scheme would end up granting all of Derby's permissions to application code. For the record, the same subversion can occur with the scheme we have today: The customer just needs to put application code into derby.jar.
> 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-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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547172 ]
Rick Hillegas commented on DERBY-3083:
--------------------------------------
Hi Knut. I don't know if you can reverse the order of (3) and (4). That might work. If it does, I agree that it's a better plan.
If we have to perform (3) first, then yes I think we need a system property to bootstrap the SecurityManager and point it at the dummy policy. I think that setPolicy would only have to be granted to the protection domain which contains the server.
But I think the first experiment would be to reverse the order of (3) and (4) as you suggest.
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540807 ]
Daniel John Debrunner commented on DERBY-3083:
----------------------------------------------
Note the purpose of the default security manager is to avoid the surprise of booting a network server providing complete access to your machine by all. Thus the least surprise should be a secure system.
> 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-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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-3083:
---------------------------------
Attachment: derby-3083-01-requireDerbynet-aa.diff
Attaching derby-3083-01-requireDerbynet-aa.diff. This implements Dan's modification to Bryan's solution. Would appreciate feedback.
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543930 ]
Daniel John Debrunner commented on DERBY-3083:
----------------------------------------------
> We seem to be talking about an attacker who has the ability to change system properties at any point in Derby's processing.
To be precise, not at any point, but while a security manager with Derby's default policy is not installed. Obviously Derby is installing a security manager because none exists, hence any code can set any system property.
Interesting case, that does require that step 2) changed the policy file to be used by the security manager, otherwise step 5) is not possible.
I'll have to investigate if it would be possible for Blackhat to do that without it being detected by Derby's checks (as-in DERBY-2362).
> 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-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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543706 ]
Rick Hillegas commented on DERBY-3083:
--------------------------------------
Thanks for the clarification, Dan. By "private to Derby" I mean that the properties cannot be overridden by any scheme that I'm aware of. For instance, someone could try to override the properties on the boot command line--but these overrides would be ignored because Derby would forcibly set the properties to values it calculated.
Fixing DERBY-2362 could reduce the vulnerability. However, I don't understand how to fix DERBY-2362. The solutions which come to my mind seem to have the same small windows of vulnerability which we're discussing here. If we could figure out how those windows could in fact be exploited then we might be able to talk about a solution.
As you note, if there is a way to exploit this window, then it can be used to subvert the value of "derby.install.url" today. The incremental exposure seems very small to me.
> 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-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.
[jira] Updated: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-3083:
---------------------------------
Derby Info: [Patch Available, Regression] (was: [Regression])
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543631 ]
Daniel John Debrunner commented on DERBY-3083:
----------------------------------------------
I hope the default policy for the network server is not granting permissions to derbytools, derbyclient or derbytesting. The original spec had carefully limited permissions intended to support running the network server.
The use of properties for the jar files names in the policy files increases a security hole, now if any code can intercept the property setting then it allows that code to grant the permissions intended for Derby to any jar on the file system. By limiting the name to derbynet.jar (etc.) that hole is reduced. To support maven maybe the name could be ${derby.install.url}derbynet${version}.jar
> 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-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.
[jira] Updated: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-3083:
---------------------------------
Attachment: derby-3083-01-requireDerbynet-ab.diff
Thanks for the quick feedback, Dan. Attaching derby-3086-01-requireDerbynet-ab.diff. You are right that endsWith() accomplishes what I want much more clearly. I have also expanded the comment on packagingLooksGood().
I am not tackling the Maven versioning scheme here. Someone else is welcome to take that on. I am tackling what I see to be the regression introduced by DERBY-2196:
1) The server crashes immediately if it can't find a jar file named derbynet.jar.
With this patch, the server will boot against the Mavenized jars--but it won't install a security manager.
I think there is a follow-on enhancement which someone else is welcome to log and tackle:
2) Make the server install a SecurityManager if the derby jars have names which conform to some other naming convention.
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546343 ]
Rick Hillegas commented on DERBY-3083:
--------------------------------------
Reverted derby-3083-01-requireDatatypes-ab.diff at subversion revision 599085 in the 10.3 branch and at revision 599086 in the trunk. There is still uncertainty about whether this is a reasonable approach to the problem. I do not think that we will reach consensus on this issue before we need to generate the next 10.3 release candidate.
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547167 ]
Knut Anders Hatlen commented on DERBY-3083:
-------------------------------------------
Hi Rick. I didn't quite get what you meant by "dummy policy" in (3). Is that a policy file with "setPolicy granted to all"? Then we need a system property, don't we? Could we achieve the same effect by performing (3) and (4) in reversed order?
> 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.
[jira] Commented: (DERBY-3083) Network server demands a file called
"derbynet.jar" in classpath
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ 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 ueberjar.
> 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: 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.