[ 
https://issues.apache.org/jira/browse/DERBY-5968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486190#comment-13486190
 ] 

Rick Hillegas commented on DERBY-5968:
--------------------------------------

Here is a script showing how this bug causes unencryption to silently fail:

connect 
'jdbc:derby:db;create=true;user=test_dbo;dataEncryption=true;bootPassword=foobarwibblewombat';

call syscs_util.syscs_create_user( 'test_dbo', 'test_dbopassword' );
call syscs_util.syscs_create_user( 'fred', 'fredpassword' );

-- shutdown the database
connect 'jdbc:derby:db;shutdown=true';

-- only the dbo can unencrypt the database
connect 
'jdbc:derby:db;user=fred;password=fredpassword;bootPassword=foobarwibblewombat;decryptDatabase=true';

-- although the connection failed, the database is now booted.
-- the following attempt to decrypt the database appears to work
-- but actually fails.
connect 
'jdbc:derby:db;user=test_dbo;password=test_dbopassword;bootPassword=foobarwibblewombat;decryptDatabase=true';

-- really shutdown the database
connect 'jdbc:derby:db;shutdown=true;user=test_dbo;password=test_dbopassword';

--  this fails because the unencryption silently failed. a boot password is 
still required.
connect 'jdbc:derby:db;user=test_dbo;password=test_dbopassword';

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

Reply via email to