Firebird 1.5.3 Client Library Security Change
2 September 2005
Many IBO applications make use of the AlterUser methods of TIB_SessionBase or TIB_Connection to provide a quick way to maintain users and passwords in the security database. This method encapsulates the three API functions isc_add_user, isc_modify_user and isc_delete_user. For IB 5.6 and below, these functions provide the only way to maintain authentication records from a user application.

At some point, Borland introduced code into the API library, gds32.dll, to attempt to make an IB user on Windows who is logged in as Administrator acquire the same capability as a Unix (or Linux) user logged in as root, to access the security database without having to log in as SYSDBA. Hence, currently, when a client calls AlterUser() from an IBO application, one of the following will happen:

1. if the Windows user is logged in as Administrator and the application does not supply the SYSDBA username and password, the client can perform the AlterUser functions

2. if the Windows user is logged in as a non-Administrator but supplies the SYSDBA username and password that are correct for the server, the client can perform the AlterUser functions

3. if the Windows user is logged in as Adminstrator and the application does supply the SYSDBA username and password, a variety of undesirable things will happen:
   • If the client is remote and there is a Firebird or InterBase server running locally and the SYSDBA password is the same on both servers, the local server will get the request and will try to update the local security database

   • If the client is remote and there is no Firebird or IB server running locally, the request will result in a number of exceptions related to Windows path resolution, that may be difficult to resolve without shutting down the server

The current situation is a source of concern to the security gurus in the Firebird development team, due to the way Windows systems are commonly set up. It is far from rare to find that many or all users on a Windows network are using the Administrator login. Implementations like IBO's AlterUser() therefore create a vulnerability for Firebird and InterBase servers, not only for Windows hosts but also for Linux hosts that are being accessed from a Windows application.

The Firebird core team has made the decision to close this hole in the Windows client library (fbclient.dll and fbembed.dll) for Firebird 2 and also to backport the change to the Firebird 1.5.3 release.

The changed client libraries are not in the Firebird 1.5.3 RC1 kits that are currently in the Firebird pre-release area for testing. They will appear in the v.1.5.3 RC2, due this month.

To test the change with any released version of Firebird (1.0.x or 1.5.x) currently in use, IBO users can download this version of fbclient.dll. Keep in mind that this version was compiled within the current Firebird 1.5 release environment and so carries the same build number as the Fb 1.5.2 release (4731). The compile date (18 Aug 2005) will be your only way to distinguish this file from the released version.

Firebird 1.5 and OldParameterOrdering [2]
November 2003
A solution has been introduced with the release of IBO v.4.3 to the parameter ordering workaround for applications accessing Firebird 1.5 servers. IBO now runs a special system query when it has connected to the server that can tell it that it is connected to a Firebird 1.5 server. It sets flags to determine how it will handle parameter ordering.

NOTE CAREFULLY that

• OldParameterOrdering should be set to 0 (the default) for applications compiled with IBO 4.3 or higher

• OldParameterOrdering should still be set to 1 for applications compiled with lower versions of IBO

Firebird 1.5 and OldParameterOrdering [1]
March 2003
IBO provides a transparent workaround for a long-standing InterBase bug that causes the ordering of return parameters to get scrambled, resulting in type mismatch exceptions or, worse, undetected wrong data when processing stored procedures.

The old bug is fixed in the Firebird 1.5 betas. Thus, the boot has changed to the other foot, meaning IBO would now "unscramble" parameters that are not scrambled. To preserve the old situation for IBO applications, the Firebird 1.5 server can be configured to deliver output parameters in the "wrong" order that IBO expects.

To set this up, do as follows:

1. Open firebird.conf in a text editor and find the parameter named OldParameterOrdering
2. Delete the '#' (comment) character
3. Change the parameter setting to

      OldParameterOrdering = 1
   

4. Save the changes
5. Stop and restart the Firebird server

Be aware that the server will deliver the reordered parameters to all client applications, not just your IBO ones. This isn't a great solution so we'll be looking for a way to make it unnecessary.

Patch for compatibility with Firebird 1.0 INSERT syntax
19 March 2002
The latest IBO 4.2Gb confirms the Firebird 1.0 compatibility patch. I understand that Claudio Valderrama has already modified his change for the forthcoming Firebird 1.0.1 point release (thanks, Claudio!) In Firebird 2, which is already in alpha, this relaxation of SQL standards is to be disallowed.

BACKGROUND :: 14 March 2002
The release of the long-awaited Firebird 1 yesterday threw up a newly-introduced problem because of an unannounced new restriction on the SQL INSERT statement. Specifically, this unpublished change breaks IBO's parsing procedure so that, when inserting from a dataset, you will get this error:

ISC ERROR CODE:335544569

ISC ERROR MESSAGE:
Dynamic SQL Error
SQL error code = -104
Token unknown - line 1, char 34
.