Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Fri, 28 Sep 2012 11:23:07 +1100 (NCT)
From: "Mamta A. Satoor (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <1637764685.136940.1348791787561.JavaMail.jiratomcat@arcas>
In-Reply-To: 
 <810502292.3491.1321988680272.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (DERBY-5510) It is easy to override
 authentication, authorization, and database-only properties if you have
 physical access to a database.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-5510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mamta A. Satoor updated DERBY-5510:
-----------------------------------

    Labels: derby_triage10_10  (was: )
    
> It is easy to override authentication, authorization, and database-only properties if you have physical access to a database.
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5510
>                 URL: https://issues.apache.org/jira/browse/DERBY-5510
>             Project: Derby
>          Issue Type: Bug
>          Components: Miscellaneous
>    Affects Versions: 10.9.1.0
>            Reporter: Rick Hillegas
>              Labels: derby_triage10_10
>
> If you have write access to the directory containing a Derby database, then the following easy exploit will let you change the contents of the database and possibly evade detection for some time:
> 1) Create a vacuous dummy database with this ij command:
>      connect 'jdbc:derby:dummydb;create=true';
> 2) Copy the properties conglomerate (c10.dat) from the target database to a side location.
> 3) Now copy the vacuous c10.dat from dummydb into the seg0 directory of the target database.
> 4) Now connect to the target database with the following ij command and change anything you want:
>      connect 'jdbc:derby:targetdb';
> 5) When you are done, copy c10.dat from the side location back into the seg0 directory of the target database.
> I do not regard this as a new vulnerability. That is because once you have write access to a Derby database directory, you have unlimited power to change and corrupt the database. However, I am filing this JIRA so that we will have a name for this particular easy exploit.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira