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-changable,
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, enbezzle money, trash data, falsify medical
records, compromise legal iformation, 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.

I went to work on a fix, an image zapper that would obliterate the
offending account and password with random byte codes. I had to
write it in the most primitive, portable C known to mankind. And
I had to drag a VAX out of my attic on which to test it. (There
were some interesting kinks due to aggressive optimization by
gcc, but that is a subject for another post.)

Getting the source trees off the net proved impossible. Source
Forge refused to shutdown access, even on a temporary basis. The
Firebird tree was duly sanitised, but Borland was unable or unwilling
to clean up their trees. Another absolutely nothing could be done
about the hundreds or thousands of copies that had already been
distributed, but most, if not all, were in responsible hands.

In parallel, Frank Schlottmann-Goedde was re-architecting
ISC4.GDB interface for Firebird, which is now available.
Mark O'Donohue (and others) sanitized the Firebird code
tree.

We were unsuccessful in reaching any responsible managers at
Borland. The switch board shut down the week before Christmas,
and no Borland official ever returned our phone calls. Our only
low level contact resulted in an order that Borland employees
have no contact with Ann or myself.

Shortly before Christmas, Cert got involved (the uncharacteristic
used by the passive is for the benefit of Borland's vindictive
legal departments). Cert (www.cert.org) is an Internet security
organization hosted by CMU. Cert did a very professional analysis
of the problem, reviewed the image zapper, offered support
and encouragement, and coordinated their annoucements with
the availability of the fix.

We also received support and encouragement from Cognos, a very
good friend of the original Interbase Software Corporation and
a former Interbase reseller. Cognos was able to build and
test the zapper on the many Interbase platforms for which we had
no hardware access.

Special thanks are also due Sean Leyne, Mike Nordel, Mark
O'Donohue, and Jim Daly for their code reviews and assistance.

The distribution site for the zapper is http://64.55.62.15
(special kudos for Network Solutions' timely name service
updates). The folks on IBPhoenix support got priority
notification (hint hint). Cert has sent out the formal
vendors' notification. Ann is preparing a message for
the various Interbase list servers, which should go out
tonight. With luck, we can get all Interbase servers
zapped before the bad guys wake up.

There are a couple of restrictions on the image zappers.
Because of the potential for a counterfeit zapper, we are
asking that zappers not be shared. If you didn't get it
from the IBPhoenix ftp server, don't run it. To slow down
the truely dim hacker, we are not releasing the zapper source.
If you think you need a copy of the source, we will require a
formal purchase order on corporate letter head.

I wish I could say that we're out of the woods on Firebird
server security. We aren't. We've fixed two egregious
screwups, but nothing in software comes in pairs. We've
closed the back door and excised the doomsday function.
We know of some the problems that remain, and we should
brace ourselves for a few more nasty surprises. But
I think we've got a solid model of protecting the installed
base while we resurrect a great product.

Good job, guys. And Frank, thanks.

Jim Starkey