[
https://issues.apache.org/jira/browse/DERBY-5968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13493412#comment-13493412
]
Rick Hillegas commented on DERBY-5968:
--------------------------------------
I have linked this issue to DERBY-2407 which also addresses the topic of
accidentally booted databases. Discussion there notes that Derby would consume
even more CPU if it deliberately brought down the database after an accidental
boot and that, in turn, would make a denial-of-service attack consume more CPU.
I think that there is a tradeoff between that denial-of-service-attack and the
current denial-of-service attack of consuming memory by leaving an accidentally
booted database up and running. And I don't think that either attack is likely
or worth worrying about.
More seriously, DERBY-2407 discusses race conditions which could arise when
more than one user tries to boot the database by connecting to it. We would
want to make sure that shutting down after an accidental boot didn't orphan
other users who are racing us to connect. DERBY-4447 might give us the tools to
do this.
I am halting work on this issue. Before proceeding further, I think we would
want to:
1) Implement DERBY-4447 so that we have a clean mechanism for handling
connection races.
2) Clean up the replication api so that we can remove the hack in
derby-5968-01-ac-shutdownDatabaseIfBootingConnectionFails.diff.
> A failed connection attempt may nevertheless manage to boot the database.
> -------------------------------------------------------------------------
>
> Key: DERBY-5968
> URL: https://issues.apache.org/jira/browse/DERBY-5968
> Project: Derby
> Issue Type: Bug
> Components: Services
> Affects Versions: 10.10.0.0
> Reporter: Rick Hillegas
> Attachments:
> derby-5968-01-aa-shutdownDatabaseIfBootingConnectionFails.diff,
> derby-5968-01-ab-shutdownDatabaseIfBootingConnectionFails.diff,
> derby-5968-01-ac-shutdownDatabaseIfBootingConnectionFails.diff
>
>
> A connection attempt may fail but still manage to boot the database. If
> possible, we should try to bring down the database after the connection
> failure.
> 1) Here is an example of this problem: If you use bad credentials to connect
> to a database, you will fail to get a connection. That's correct behavior.
> However, Derby must boot the database in order to discover its authentication
> mechanism. The database remains booted after this check.
> 2) There are other examples of this problem. For instance, if a user with
> good credentials tries to change the boot password on an encrypted database,
> then the connection attempt will fail, but the database will remain booted.
> This can cause silent failures on later attempts to re-encrypt or un-encrypt
> a database after the low-privilege or nonexistent user manages to boot the
> database. The connection attempt will succeed, leading the DBO to think that
> the re-encryption worked. But actually re-encryption did not take place
> because the database was already booted.
> I regard this silent failure as a security vulnerability.
> The following script shows problem (1):
> connect 'jdbc:derby:db;create=true;user=test_dbo';
> call syscs_util.syscs_create_user( 'test_dbo', 'test_dbopassword' );
> -- shutdown the database
> connect 'jdbc:derby:db;shutdown=true';
> -- need credentials in order to get a connection
> connect 'jdbc:derby:db';
> connect 'jdbc:derby:db;user=test_dbo;password=test_dbopassword';
> select count(*) from sys.systables;
> -- shutdown the database
> connect 'jdbc:derby:db;shutdown=true;user=test_dbo;password=test_dbopassword';
> -- try to shutdown the database again. since it is already shutdown, you will
> get a message saying it can't be found.
> connect 'jdbc:derby:db;shutdown=true;user=test_dbo;password=test_dbopassword';
> -- now try to boot with bad credentials. you don't get a connection but the
> database boots.
> connect
> 'jdbc:derby:db;user=alice;password=alicepassword;bootPassword=foobarwibblewombat';
> select count(*) from sys.systables;
> -- the shutdown command succeeds because alice managed to boot the database
> -- even though she isn't a legal user.
> connect 'jdbc:derby:db;shutdown=true;user=test_dbo;password=test_dbopassword';
--
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
