Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <4193093.1195505923257.JavaMail.jira@brutus>
Date: Mon, 19 Nov 2007 12:58:43 -0800 (PST)
From: "Daniel John Debrunner (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-3083) Network server demands a file called
 "derbynet.jar" in classpath
In-Reply-To: <17082838.1190192623682.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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.