Alexander Peshkov Added File:
README.sha1
Log Message:readme for security review
Content:
IF YOU GET MESSAGE "cannot attach to password database"
TRYING TO START FIREBIRD AFTER UPGRADE FROM 1.5, PLEASE READ ~/upgrade/v2/security_database.txt.
WARNING! Firebird security level is still not satisfactory in one serious aspect, therefore carefully read this document before opening port 3050 to "big dirty" net.
Very important security problem of firebird, which is still unresolved - transmission of badly encrypted passwords (read - clear) across network. Unfortunately, it's impossible to solve this problem without breaking old clients, i.e. user who has set password using new secure way will not be able to attach to the server with old client. This fact (and plans to upgrade some aspects of API in next version) lead to decision not to modify way of passwords transmission in firebird 2.0. Fortunately, this problem may be easily solved using any IP-tunneling software (like ZeBeDee) to move data to and from firebird server (this is true for both 1.5 and 2.0) and this is recommended way to access your remote firebird server across internet.
Special attention was paid on the following aspects of security:
- none brut-force resistant passwords encryption in security.fdb;
- ability for any remote user (with valid account) to open security.fdb and read hashes from it (specially interesting in combination with previous point);
- inability for user to change his own password;
- no protection from remote brut-forcing of passwords on the server directly.
Lets have a look at the process of user identification in firebird 1.5. DES algorithm is used to hash password twice - first by client, next by server before comparison with hash stored in security database. But this sequence becomes completely broken when one SYSDBA changes password - client performs hash calculation twice and stores resulting hash directly in security database. Therefore hash management is completely client-dependent (or even better to say client-defined). To be able to use stronger hashes another approach should be used - hash to be stored on the server is always calculated by server side. And such schema already exists in firebird - this is services API. Therefore decision was made to use services API in any client activity related with users management. For today gsec and isc_user_add(modify,delete) API both use services to access security database (with exception of embedded access to POSIX CS, see below). Now it became quite easy to make any changes to way of passwords hashing - it's always performed by server. Should notice, that new gsec successfully works with old firebird versions - as long as server supports services, it's not a problem of gsec, how will be calculated the hash for security database, it simply asks services to do the work!
New hashing algorithm, selected for firebird 2.0, is SHA-1. Data, stored in PASSWORD field of security database, contains two parts - some random number, used as salt for calculating this particular hash, and hash itself (it's calculated as SHA1 (salt || username || password)). This method leads to the facts that (first) hash valid for user A is invalid for user B and (second) when user changes his password even to absolutely the same as later, new data is stored in PASSWORD field of security.fdb. This facts don't increase resistance to any attempt to brut-force password, but make "visual" analysis of stolen password database much harder.
One of the problems, solved during security review, was old gsec. Certainly, no one can change data in security database without correct password knowledge, but it's relatively easy to use old version of gsec. It will write bad old hash in PASSWORD field, and if LegacyHash parameter of firebird.conf is set to 0 (this is default, 1 should be used only during upgrade process), login to server becomes impossible. Therefore special measures were taken to make remote connection to security database impossible at all. Don't be surprised if some old program, trying to use such direct access, fails - this is by design, only services API (and isc_user_* API functions, in turn using services internally) may be used now to access users info.
Structure of security database was changed. In general, now it contains patch by Ivan Prenosil, enabling any user to change his own password. But there also some small differences. In firebird 1.5 table USERS had to be readable by PUBLIC - it was engines requirement, other case process of password validation failed. In Ivan's patch solution with view, having condition USER = '' in where clause, was used. That worked due to another bug in engine, which left USER SQL variable empty, not 'authenticator', as it might seem from engine's code. After fixing that bug, it was certainly possible to add condition USER = 'authenticator', which in short-term was OK, because normal username is always converted to upper case. But better solution was found, and now user authentication process does not depend from such tricks. As the result - non-SYSDBA user can see only his login in any user-management tool (gsec, any GUI, which uses services API). SYSDBA certainly has full access to manage users' accounts.
The chance left for hacker to break firebird installation is trying to brut-force password. Taking into account, that maximum password length is 8 bytes, this is a bit possible for firebird. Version 2.0 has protection from it - after too many attempts to enter wrong password authentication process is locked for a while, minimizing the chance of finding correct password during reasonable time.
POSIX classic server.
For some technical and historical reasons, this kind of installation is specially dangerous from security point of view. Users, having embedded access to databases, MUST be given at least read access to such critical place as security database. This is the main reason that no matter of the fact that in firebird 2 security database is protected from any remote access, use of enhanced password hashes in it was really required step. Imagine malicious user, having user-level access to firebird. He can easily steel security database, take it home and quietly brut-force old DES hashes! After it he can change data in critical databases, stored on that server - specially dangerous kind of attack. In firebird 2 such activity was made much harder to perform.
But embedded POSIX server has one more problem with security - services API on it uses that same command line gsec, as normal users do. Therefore this utility must have full access to security database. Luckily, the main reason to reason to restrict direct access to security database was protecting from use of old versions of client software. But it's quite unlikely to have old client and new server on the production box. Therefore current solution of giving full embedded access to local security database in embedded mode is not too dangerous.
No
Limited*
