Bugzilla Bug 216158

After fresh installation firebird server allows connect with administrative
account (SYSDBA) without password.
gbak  -v -t -b -user SYSDBA  192.168.1.1:database test.gbk
Password may be any. Only SYSDBA account is affected.
Firebird server version: Superserver
USE="-debug -doc -examples -xinetd"
Kernel 2.6.23
Compiled by GNU CC version 4.1.2 with nptl support

cc'ing maintainer

Seems, problem is in startup script.  The environment variables ISC_USER and
ISC_PASSWORD must be defined only for server shutdown (stop()).  When defined
before start, server uses them as something like windows trusted  connection ?
Why ???

Ok it seems the server uses it's env vars set at startup for remote client
connections when a password is not set. Upstream says those vars should not be
set in the env. So easy way to correct that. Just comment out the exports in
the init script, and if you want the username/password in conf.d/firebird.

Now upstream also says one should not use fbmgr.bin to stop firebird. Really
that's why the username and passwords are set and exist in the env file. So it
can be shutdown using commands.

Upstream is recommending to kill the process, or use start-stop-daemon. Which I
would love to, but I haven't been able to capture the pid on startup. Due to
how it forks. You invoke ibmgr.bin then it forks fbguard and it forks fbservers
:) And we need the PID to fbguard. Otherwise we can do a killall fbguard
fbserver. But I really don't like that much.

At the same time I agree with upstream having passwords in files suck. Them
being set at startup and runtime is pointless. So maybe for now I just move the
exports to the stop function. That way they are only set when really needed.

If you do that, you will have to make sure they are not set after the stop()
function finishes, because that would introduce the problem when people
restart.

Doesn't firebird write a .pid by itself? How do other people/upstream handle
their kills/stops?

(In reply to comment #4)
> If you do that, you will have to make sure they are not set after the stop()
> function finishes, because that would introduce the problem when people
> restart.

Yeah need to move away from that approach entirely.

> Doesn't firebird write a .pid by itself? How do other people/upstream handle
> their kills/stops?

I guess it can create it's own pid file. I wasn't aware of that. Taking a look
at some init scripts in the sources. 
echo $MANAGER -pidfile $pidfile -start -forever | su $FBRunUser

Then to stop they do
kill `cat $pidfile`

I think that's quite nasty. But upstream says it will stop it gracefully? I
inquired about transaction clean up and etc. No response, so I guess that's how
they want it stopped.

Seems mighty strange to me, but I guess they have the same shutdown hooks in
kill operations?

I will see about updating the init script ASAP. Likely request immediate
stabilization afterward, Since this is a sec issue.

They ship a init script for Gentoo, I will look to start using it or aspects of
it.

Ok, just re-did the conf.d file and init scripts. Username and passwords can be
removed from conf.d. Or just overwritten with etc-update, some new vars in that
file. Switched to using s-s-d for start and stop. Added restart function.
Resolves bug, thanks for reporting. This was very much Gentoo specific. Legacy
cruft in our init process.

We'll still need to get this thing stable, and decide on GLSA'ing it.

We could wait another day for users to test, or cc arches now. Let me know what
you prefer.

Duh, sorry good thing you caught before I filed a stable request. Forgot sec
process there for a sec. Take it from here :)

Changes are basically how upstream invokes it, and I got the stuff from them
and Firebird sources. I tested locally remotely, etc. I have no problem with
others testing. Surely before stabilization. Shouldn't be any problems and
should be resolved.

Definitely needs a GLSA.

Also while this is totally my bad for not catching. Upstream mentioned it to me
a few months back, about not needing ISC username/password in env for start.
And using other ways to stop. It was in a discussion of other things and I just
missed it. At the same time I was not aware it would cause a vulnerability like
this. And while I accept full blame, I did not add the conf.d and init stuff to
tree, ISC stuff, etc. Just took it over and did some updating as I split FB up.
But I should have caught it either way, much less when upstream mentioned.

Four days without a bug report, I'll cc arches.

Arches, please test and mark stable:
=dev-db/firebird-2.0.3.12981.0-r6
Target keywords : "amd64 release x86"

amd64/x86 stable, last arches; please note:

dodoc: examples/* does not exist

for the impact section of the GLSA, does the SYSDBA user have any limitaions or
is this equivalent to full disclosure of all data?

(In reply to comment #12)
> for the impact section of the GLSA, does the SYSDBA user have any limitaions

Not really in db terms SYSDBA is root, god, all perms, even if not granted. I
think if tried to revoke, dbs wouldn't function properly.

> is this equivalent to full disclosure of all data? 

Full disclosure :( massive gapping whole. They can back up any database, except
for the security2.fdb since it's internally protected. 

Does that include write access to every database? User accounts cannot be added
or deleted?

Well it doesn't give you direct write access. But I assume you could restore a
database on top of another. I haven't done that myself. Surely they could
restore the db else where on the system.

I don't believe they have any access or ability to effect user accounts and/or
paswords. Since they can't backup or write to the security2.fdb. Shouldn't have
anything exposed or vulnerable there. Thankfully due to internal security
mechanisms ;)

Mostly a data leak issue. People could back up your dbs, and have all of your
data. All except for security2.fdb. Now they would have to know the exact path
to the database and file name. And/or if they users setup any db aliases, the
remote party would need to know the alias.

So while it's a gapping hole, it's not easily exploited without some intimate
knowledge of the system being attacked/backed up from.

While this is Gentoo specific. It can happen if users export ISC username and
password variables in the env the engine is running in. I mentioned that's not
ideal to upstream. Which is where this comes from in the first place. I am not
sure if they will address that or not. But might want to mention it in GLSA.
Since even if they use the newer ebuild, init file and conf.d file. The ISC
stuff is gone, but the user might export that for some reason. Which again if
available in env engine is running in. Exploit would be possible, even despite
my efforts.

Fixed in release snapshot.

GLSA 200805-06