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.