TUCoPS :: Unix :: General
:: ibase2-1.htm
InterBase backdoor - present since 1992, finally fixed in 2K1!
Vulnerability
InterBase
Affected
Borland/Inprise Interbase 4.x and 5.x, Open source Interbase 6.0
and 6.01, Open source Firebird 0.9-3 and earlier
Description
Ben Greenbaum posted following. It has been found that a backdoor
has been coded into InterBase since 1992. This previously-secret
account has full access and an unchangeable, known username and
password. With this knowlege, attackers can remotely gain read
and write access to any database on the server.
During development of Interbase Version 4, the Borland engineers
(sic) hard coded a security back door into the Interbase database
engine. One of the version 4 features was the ISC4.GDB security
(sic) database, used to authenticate user names and passwords.
The design revolved around two ideas. First, the security
database was just another database. Second, the database engine
itself required special access to the security database for
obvious reasons. The solution implemented by the Borland
engineers was to hard code a magic account of password that the
engine would both pass to the security database and recognize as
giving god-level (to quote the code) access.
The magic account and passwords were compiled in, non-changeable,
and were among the stupidest account/passwords pairs ever
invented: mention the account name and 8 out of 10 people would
guess the password on the first try. Given the account and
password pair, a hacker could attach any Interbase database on
any platforms for all Borland Interbase versions between 1994 and
2000. Once attach, a hacker could fetch anything and everything
in a database, give himself a raise, steal month, disclose trade
secrets, embezzle money, trash data, falsify medical records,
compromise legal information, and anything else his little
malicious heart decided. The only two thing protecting the many
tens of thousands of InterBase databases was that the account and
password were nominal secrets, and that nobody suspected that
doing an ascii dump of the Interbase engine would reveal two words
that had absolutely no business being inside of a database engine
and use them to logon to any Interbase database. Unfortunately,
the back door wasn't the only problem that came to light.
According to comments in the code, in 1994 Borland's QA department
demanded that a "unpublished" build in function be implemented to
delete the database file while the server was running. Unlike the
security back door, however, the engineer who implemented the
function carefully documented the function, the implications, the
fact that no customer should ever be aware of the function, then
signed and dated the code. But like the security back door, the
doomsday function is in all versions and all platforms of
Interbase from 1994 to 2000. In July of 2000, Borland published
the source code. It apparently didn't occur to the Borland
engineers that inserted the back door in the first place and used
it for other purposes during version 6 development that a security
back door was sufficiently dangerous to call it to the attention
of their management or a responsible adult. In the week before
Christmas, a responsible Firebird developer stumbled into the
code and recognized both the back door and the implications.
Happily (so far) for the Interbase/Firebird community he posted
the problem to the very small Firebird admin list. Several
things were obvious:
0. We needed a fix for all versions and all platforms.
1. Until as fix was ready to be distributed en mass, the problem
had to be kept secret.
2. We needed to get the various source trees containing the
account/password off the net before word of the back door
leaked out.
3. We needed to get the attention of Borland's management.
4. We needed help.
5. We need an immediate fix to Firebird.
The essence of the problem is this. Once we had a fix we couldn't
distribute it without telling people it was there. But telling
the users without tipping off the hackers was impossible,
particularly since any programming, knowing only that the back
door existed, could find it in the source in about 5 minutes.
Shortly before Christmas, Cert got involved (the uncharacteristic
used by the passive is for the benefit of Borland's vindictive
legal departments). Cert did a very professional analysis of the
problem, reviewed the image zapper, offered support and
encouragement, and coordinated their announcements with the
availability of the fix.
This back door allows any local user or remote user able to access
port 3050/tcp [gds_db] to manipulate any database object on the
system. This includes the ability to install trapdoors or other
trojan horse software in the form of stored procedures. In
addition, if the database software is running with root
privileges, then any file on the server's file system can be
overwritten, possibly leading to execution of arbitrary commands
as root.
The back door account password cannot be changed using normal
operational commands, nor can the account be deleted from existing
vulnerable servers.
Solution
Both Borland and The Firebird Project on SourceForge have
published fixes for this problem. If you do not see your vendor's
name, the CERT/CC did not hear from that vendor. Please contact
your vendor directly. Users who are more comfortable making their
own changes in source code may find the new code available on
SourceForge useful as well:
http://sourceforge.net/projects/interbase
http://sourceforge.net/projects/firebird
Block access to port 3050/tcp. This will not, however, prevent
local users or users within a firewall's adminstrative boundary
from accessing the back door account. In addition, the port the
Interbase server listens on may be changed dynamically at startup.
Borland
=======
Please see:
http://www.borland.com/interbase/downloads/patches.html
IBPhoenix
=========
The Firebird project uncovered serious security problems with
InterBase. The problems are fixed in Firebird build 0.9.4 for
all platforms. If you are running either InterBase V6 or
Firebird 0.9.3, you should upgrade to Firebird 0.9.4. These
security holes affect all version of InterBase shipped since
1994, on all platforms. For those who can not upgrade, Jim
Starkey developed a patch program that will correct the more
serious problems in any version of InterBase on any platform.
IBPhoenix chose to release the program without charge, given the
nature of the problem and our relationship to the community. At
the moment, name service is not set up to the machine that is
hosting the patch, so you will have to use the IP number both for
the initial contact and for the ftp download. To start, point
your browser at
http://firebird.ibphoenix.com/
Apple
=====
The referenced database package is not packaged with Mac OS X or
Mac OS X Server. Fujitsu Fujitsu's UXP/V operating system is not
affected by this problem because we don't support the relevant
database.
IBM
===
IBM's AIX operating system does not incorporate the Borland
Interbase server software.