db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2407) A connection attempt by an unauthorized user leaves a previously non-booted database booted
Date Tue, 06 Mar 2007 19:57:24 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478545

Dag H. Wanvik commented on DERBY-2407:

Hi Dan,

Daniel John Debrunner <djd@...> writes:

> 1) If a boot with failed authentication shuts the database down, then
> at least it has to ensure that no valid user has connected to it since
> it was booted.

Yes, I thought of that.. but think I'll have to handle that as part of
policing encryption boot anyway (DERBY-2264): Is there a (simple) way
to block other connections while doing a boot, credentials check and
then shutdown/reboot with encryption?  One would want to make this

> 2) Having such a request shutdown the database might actually increase
> the potential of a denial of service attack. More work would be
> performed for an invalid request, thus consuming more cpu time on the
> machine.

I agree. But unauthorized boots may interfere with dba activity; if a
dba does a shutdown to prepare for an encryption reboot, that reboot
might not be performed as attempted if the database was rebooted by
someone else (by somebody unauthorized or not) in the meantime. This
is compounded by the fact that if db is already booted, it seems that
boot parameters are silently ignored, is that by design or accident?

Not exactly a denial-of-service attack, perhaps, not sure how serious
this is, but it seems a hole to me.

But fixing this might open the kind of DoS hole you are pointing to,
not sure which hole is more serious. Maybe one could keep a cache in
the engine of (already) failed login credentials to alleviate that
(except when external authentication is used, of course)?

> 3) Which "end-user" do you mean above? A remote user can't tell that
> the database was booted or not so it's not surprising to them. :-)

I thought of a dba, sorry for my lack of precision.

> A connection attempt by an unauthorized user leaves a previously non-booted database
> -------------------------------------------------------------------------------------------
>                 Key: DERBY-2407
>                 URL: https://issues.apache.org/jira/browse/DERBY-2407
>             Project: Derby
>          Issue Type: Improvement
>          Components: Services
>    Affects Versions:,,,,,,
>            Reporter: Dag H. Wanvik
>            Priority: Minor
> File this as a placeholder for the discussion started in 
> http://www.nabble.com/no-protection-of-db-boot---intended--t3293929.html
> This may or may not be a behavior we would like to change.
> (first mail):
> Working on DERBY-2264, I notice (again) that booting a database is not
> protected in any way.  Currently, even when authentication
> (derby.connection.requireAuthentication) is turned on, any user can
> leave the database in a booted state: If not already booted, the
> database potentially needs to be booted to authenticate. However, if
> authentication fails, the database is not shut down again. Thus, an
> invalid user is allowed to change the database state. I think this is
> somewhat surprising for an end user. Is there a reason for this
> behavior?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message