no protection of db boot - intended?

["Dag H. Wanvik" <Da...@Sun.COM>]

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? If not, I will file a JIRA for fixing it.

Thanks,
Dag

Re: no protection of db boot - intended?

["Dag H. Wanvik" <Da...@Sun.COM>]

Hi Francois,

thanks for your reply. Please (also) see my reply to Dan.

Francois Orsini <fr...@gmail.com> writes:

> Not sure I understand this completely - What do you mean by "Thus, an
> invalid user is allowed to change the database state"? if the database is

I meant the boot state, which may be significant for a dba.

> booted and left opened, it still requires users to authenticate to get a
> valid connection to it, _if_ derby.connection.requireAuthentication was set
> to true. The database can stay open as it is required to be online so that
> user authentication works...Yes, we could shut it down again if it was not
> being booted before *but* then one also has to handle the possibility of
> concurrent user authentication requests and if the first one requiring the
> db to be booted in the first place, should we shut it down then? I mean yes
> we could do and try such a thing but it's not like the database data are
> being made available since no invalid user will be able to authenticate
> anyway...This is *not* a denial-of-service attack - Again, the db data is
> not made available to invalid user(s)...

Dag

Re: no protection of db boot - intended?

[Francois Orsini <fr...@gmail.com>]

Hi Dag,

Not sure I understand this completely - What do you mean by "Thus, an
invalid user is allowed to change the database state"? if the database is
booted and left opened, it still requires users to authenticate to get a
valid connection to it, _if_ derby.connection.requireAuthentication was set
to true. The database can stay open as it is required to be online so that
user authentication works...Yes, we could shut it down again if it was not
being booted before *but* then one also has to handle the possibility of
concurrent user authentication requests and if the first one requiring the
db to be booted in the first place, should we shut it down then? I mean yes
we could do and try such a thing but it's not like the database data are
being made available since no invalid user will be able to authenticate
anyway...This is *not* a denial-of-service attack - Again, the db data is
not made available to invalid user(s)...

--francois

On 2/26/07, Dag H. Wanvik <Da...@sun.com> wrote:
>
>
> 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? If not, I will file a JIRA for fixing it.
>
> Thanks,
> Dag
>

Re: no protection of db boot - intended?

["Dag H. Wanvik" <Da...@Sun.COM>]

Hi Dan,

Daniel John Debrunner <dj...@apache.org> 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
atomic..

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

Dag

Re: no protection of db boot - intended?

[Daniel John Debrunner <dj...@apache.org>]

Dag H. Wanvik wrote:
> 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? If not, I will file a JIRA for fixing it.

Not sure there's a reason for the behaviour, but I'm not sure the fix is 
obvious.

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.

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.

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

Dan.

Re: no protection of db boot - intended?

[Rick Hillegas <Ri...@Sun.COM>]

Dag H. Wanvik wrote:
> 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? If not, I will file a JIRA for fixing it.
>
> Thanks,
> Dag
>   
Hi Dag,

This sounds akin to a denial-of-service attack. I agree that it deserves 
its own JIRA.

Regards,
-Rick