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"
Compiled by GNU CC version 4.1.2 with nptl support
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
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:
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.