db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (Updated) (JIRA)" <j...@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.
Date Tue, 22 Nov 2011 19:06:41 GMT

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

Rick Hillegas updated DERBY-5510:
---------------------------------

    Description: 
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.


  was:
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 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.


    
> 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.0.0
>            Reporter: Rick Hillegas
>
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message