by Mark O'Donohue 21st January 2001
Overview
Firebird/InterBase works in three modes, direct file access, classic client server and the more recent superserver model. Before we look at security it is important to determine which mode or modes you are going to use and allow Firebird/InterBase to be used.
In the following discussion I use the term "Firebird/InterBase system files" these refer to the files such as the user database isc4.gdb, isc_event1.<hostname>, isc_init1.<hostname> and isc_lock1.<hostname> all of which in the Linux world are generally found in /opt/interbase. It should be borne in mind that this discussion is primarily aimed at Linux/Unix platforms, although most of the material will also be relevant to Win32.
Direct File Access
The most efficient method is direct file access to the database file, in this mode the database access engine runs with the privileges of the current user executing the program. A by-product of the direct access approach is that the running user has to have read and write access to all the Firebird/InterBase system files and to the database.
Classic Server
The Firebird/InterBase Classic Server registers itself as a unix service, each client process that makes a network connection to the server machine using port 3050 forks off its own child server process (in some cases running under the unix uid/gid of the requesting client process). Each spawned server process services requests from one specific remote client. A single server machine can support many separate client processes, by creating separate processes each of which run concurrently (multitasking).
All of the unix user names used on the server processes (including those forked processes running as their own unix users) need to have access to FB/IB system files. Depending upon the number and variety of your users that could be one person, a few - perhaps enough to put into a unix group or it could be everyone. The bottom line is that all of the unix users under which the server process (and its setuid child processes) will run have to have read and write access to the sensitive FB/IB system files.
This is currently the model I run on Linux and is also considered the most simple and stable in a Unix environment, since it has been around for quite a while.
(It is also possible to use both classic server access and direct access modes at the same time, say remote users, and some server tasks connecting directly. The locking and other contention issues will be automatically managed by the database engine).
SuperServer
More recently a multi-threaded architecture has been implemented where all of the separate server tasks share the same address space, and where possible multiple threads can be used in a single client request. In this mode the server runs as a privileged user (usually as either a root/firebird/interbase or interbas user) and only that privileged user needs to have access to the Firebird/Interbase system files.
SuperServer has been around since v4.2 in the win32 environment. It has been available since V5 under Solaris, but has only been available under Linux since InterBase V6.0.
Configuration Suggestions
The following suggestions apply mainly to both the server versions of Firebird (classic and super) . Here's my recommendation list so far:
Ensure UDF definitions can only be made by trusted users.
A UDF procedure runs in the same address space and with the same privileges as the server process. It is important that any UDF procedures allowed to run in interbase have been viewed and installed by trusted users/administrators.
Ensure that tables that map to files can only be made by trusted users.
It is possible in the schema to map individual tables to specific files on the operating system. Where interbase is running in a server environment this allows the remote user to modify/create files with the same privileges as the owner of the server process.
Ensure that machines that run the client processes are trusted, and that every user with access to the client machine is trusted.
Once specified that the FB/IB server trusts the client machine, there is an explicit trust by the server of all information sent from the client to the server. This includes at times privileged information such as the username under which the client process is running. It is possible for a rogue user running on a trusted client machine to feed the server incorrect information and gain privileged access to databases on the server.
If running a web server or n-tier application process then ensure that non empty username/password are enforced.
There are some nasty defaulting effects on relying on default user names, with the net result being that not specifying a username/password may result in you gaining the privileges of either the owner of the client process or possibly even the owner of the server process. The best way to ensure that this does not happen in an n-tier application is to make sure that a username is explicitly specified before a call to the client FB/IB process is made.
The specific locksmith user problems and qatest problems have been removed via patch or new version.
Recently as part of a security audit, a backdoor hard coded 'locksmith' account was found in the source code. In addition a number of unwise "QA" functions were also found in the code. These seem to have been in InterBase since V4. The latest versions of Firebird 0.9-4 and Interbase (6.01) have these removed, and a binary patch can be applied to remove the problem from prior versions (see Security Alert for ibphoenix patch by Jim Starkey, or Borland for Borland's patch.)
Don't run server as root user.
The default installation for Linux installs the FB/IB server as owned and run by root user. This does not have to be the case, and indeed should not be the case for a secure installation. A script file is provided in the linux install to change the run user, (/opt/interbase/bin/CSchangeRunUser.sh). In InterBase the process for changing the runtime user is described in the documentation. (Firebird will shortly change the default install, since it is bad karma to have an insecure setup result from a default installation).
Change the sysdba password from it's default value.
The default sysdba password of 'masterkey' is widely known and obviously insecure. To secure an installation default passwords, particularly those of such powerful accounts, should be changed at the first opportunity. Currently the Linux Firebird install will automatically generate a new unique password on install, and this functionality will make its way slowly to the other platforms.
Passwords are restricted to 8 chars so are susceptible to brute force attack. Ensure isc4.gdb is only visible to appropriate users and put a procedure in place to monitor and lockout repeated logon attempts.
The password encrypt/hash algorithm is based on a DES hash algorithm. It (in the true tradition of early unix) uses only the first 8 characters to form the hash. With the computing power available today, these passwords are fairly easy to break using a brute force attack (i.e. try every combination of up to 8 chars). However a brute force attack require lots of attempts at entering the password. This is most easily done by stealing the password file (isc4.gdb) and trying it all remotely, or repeatedly trying to logon through your webserver. Restricting visibility of the isc4.gdb security file, and putting in place procedures to monitor and lockout repeated logon attempts will help reduce your exposure to this problem.
Change passwords regularly and keep them secure.
And the old favorite, but most often the cause of security breaches, keep your password secure. Putting the username/password on a post-it note on the computer, or choosing 'password' as your password isn't secure, and should not be done particularly for sensitive accounts.
Restrict client <-> server network communication to trusted network.
Much of the communication between the client and the server carries sensitive information. And this information can easily be gained by someone listening to network communications. For instance, even the encrypted password sent from the client to the server could potentially be used to gain access to the server. So it is important to ensure that the network path between the client and the server are over a trusted network, say through a local company network behind a firewall. I believe there is also an InterBase add-on product available that will provide an encrypted network tunneling pathway solution.
Keep the server behind a firewall.
When you have your server system locked down, and on a secure network, and with the specified trusted client machines identified, there are no additional problems that I'm currently aware of. However, placing your server machines behind a firewall is always a good idea. I'll assume the reasons are obvious and you already know why.
Keep the CLIENT process behind a firewall.
As mentioned previously the server implicitly trusts the client process, so it is important that the integrity of the client process is not compromised. Again for obvious reasons, keeping the client process behind a firewall is a good idea.
Buffer Overruns - Checking lengths of user entered fields.
There are a large number of string copy commands in the FB/IB code (strcpy, memcpy) that do not check the length of the data they are about to copy. Although a large number of these are probably safe, usage of these functions is nowadays not recommended as these are a classic source for buffer overrun attacks against a system. It is possible that some of these overruns may be able to be manipulated externally by passing large strings of binary data into SQL statements or pushing random rubbish into the server port 3050.
I must emphasize here, that there is currently no known exploit, but that there is the potential for one to exist. These are more easily exploited if the server and/or client process are not behind a firewall or running on trusted systems, so again it's worth putting them behind a firewall. Then the only way to pass data through to the client and server is via your defined client process, be that an asp or jsp web page. At this point, as an additional check you may wish to do some defensive programming, and check for reasonableness in the length of fields entered by users in the web page data entry page (a logon name > 8k for instance is probably an indication that something is not quite right).
Restrict access to system files for direct connect mode to the runtime users.
In direct connect mode (the norm for embedded systems) the runtime user has to have physical direct read and write access to both the database and the FB/IB system files. You should restrict ownership/access of the system files so that only the required users have access to the FB/IB system files.
If you have two (different) run time users on the same box who both use a direct connect mode to separate database, then both users need to have write access to the system files.
In the direct access only model, although the user has complete read and write access to the FB/IB system files, it is not possible for them to exploit any weakness in the server process to gain additional privileges, as there is no server process to exploit.
So what can be considered secure?
For instance - a web server that connect to the FB/IB server, where the database server and the web server are pretty well protected using firewalls and the web server is locked down, is quite likely to be secure, particularly if your web server code (asp or jsp) checks the length of code variables passed into the FB/IB client software (perhaps even by checking the length of the resulting sql statement). Here the potential for exploitation is fairly minimal.
If you are running FB/IB behind a firewall on a local network with one (or more) servers and many client user machines then you need to trust those local lan users that they will at least run the client software as expected. Simple things like tracing all the database ip traffic is likely to give you some sensitive user information, and the potential exists for someone to send a bucket load of rubbish down the 3050 port to try and kill the server or try some buffer overflow exploit. This is pretty much the state of play for a lot of local lan applications at the moment, so FireBird/Interbase is not alone there (this is not an excuse mind you, and there is certainly room for improvement).
Solutions and Improvements
Much can be done to improve the security aspects of FB/IB, these are however a topic for another discussion. Many of the smaller issues, such as upgrading the password hash algorithm (it should probably now be SHA1 or MD5 of the string "salt+ username + password"), and making the default installation on Linux not one that runs as unix root user, are fairly easy and need to picked up fairly soon.
The big picture issue here, relating to user authentication and secure client-server communication is not unique, and many good solutions already exist in other opensource projects. My preference is to use a Public Key Infrastructure (PKI) solution for authentication and SSL where appropriate for secure communications. Fortunately most of this is available in the OPENSSL project, and even more fortunately some of us have some coding experience with it's predecessor project SSLEAY.
In Conclusion
At Firebird the security audit continues, but we believe that we have fairly clear design solutions to the current limitations/problems that will make Firebird a more secure and robust product suitable for use in the untrusted internet world of today.
However it will be a while before all of this work can be done, since we are all here in our spare time, and have our day jobs and real lives to contend with as well. In addition, aided by the recent problems, it is likely some of the script kiddies will be now looking through the code, and it's safer to assume they will find any exploits in the areas mentioned above. So until we finish it is important that people that are going to use FB/IB have good information about how to set up and run their installation securely.
In addition to the points suggested here, and looking at the documentation available, it is probably a good time to keep an eye on a few extra newsgroups/newslists and sites, for a while anyway, since if any further information is found it is likely to first appear in these newsgroups. Firebird-devel and ib-architect are no longer available through the mers newsserver although we hope to find an alternative news-server soon.
Any further problems we (at Firebird) find are likely to flow through the same information path as the previous problem. This includes notifying Borland, notifying CERT (IBPhoenix will be aware of it since Ann Harrison is on the Firebird project) and participating in producing a patch/update for the problem.
I have no idea how Borland or IBPhoenix will respond to a future security alert, but suspect that the recent alert is probably a good guide and hopefully lessons have also been learnt. So joining CERT or monitoring some technical FB/IB newsgroups is a good idea. If it is critical you get the information ASAP then establishing a relationship with IBPhoenix (or possibly Borland) is also a good idea.