(old) informix security hole with ruserok() style security

[nneul () UMR EDU (Nathan Neulinger)]

I have received a number of questions recently (one even from a
programmer at the federal reserve bank) regarding this hole I mentioned
back in 1998. Instead of replying to each of them individually, I figured
it'd be easier to just post the detailed information to this list again.
Some of this full description was never posted to the list, just in
individual replies. Two notes follow - one was my posting to CERT, the
other is a reply I sent to a person asking about my bugtraq note.

As a note - I am no longer using Informix, so I really can't verify this
or anything for newer/older versions of the code.

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul () umr edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216

Version 1.0
October 1996
                        CERT(sm) Coordination Center
                Product Vulnerability Reporting Form

            We prefer that any vulnerability information you
          send to us be encrypted. We can support a shared DES
          key or PGP. Contact the CERT staff for more information.
          The CERT PGP public key is available in

                     ftp://info.cert.org/pub/CERT_PGP.key

    Thanks, we appreciate your taking the time to report this
    vulnerability.

CONTACT INFORMATION
===============================================================================
Let us know who you are:

 Name                   : Nathan Neulinger
 E-mail                 : nneul () umr edu
 Phone / fax            : 573-341-4841
 Affiliation and address:
        University of Missouri - Rolla
        114 Math/Computer Science
        Rolla, MO, 65401

Have you reported this to the vendor?  [yes/no] no

        If so, please let us know whom you've contacted:

        Date of your report     :
        Vendor contact name     :
        Vendor contact phone    :
        Vendor contact e-mail   :
        Vendor reference number :

        If not, we encourage you to do so--vendors need to hear about
        vulnerabilities from you as a customer.

POLICY INFO
===============================================================================
We encourage communication between vendors and their customers.  When
we forward a report to the vendor, we include the reporter's name and
contact information unless you let us know otherwise.

If you want this report to remain anonymous, please check here:

        ___ Do not release my identity to your vendor contact.

TECHNICAL INFO
===============================================================================
If there is a CERT Vulnerability tracking number please put it
here (otherwise leave blank): VU#   INFO#97.33972

Please describe the vulnerability.
- - ---------------------------------

What is the impact of this vulnerability?
- - ----------------------------------------
 (For example: local user can gain root/privileged access, intruders
  can create root-owned files, denial of service attack,  etc.)

   a) What is the specific impact:

In short:
        Enabling network access via trusted hosts with Informix opens up
        the database server to complete and total access by ANY userid on
        the trusted host.

        As a secondary effect, the database servers capability of
        unloading data to files in an account from a remote connection
        has the potential to allow breakins to individual users accounts.

Informix 5.x and 7.x (probably all versions using Informix-NET)
purport to support BSD rhosts()/hosts.equiv mechanism for network access
control. However, the server relay process (sqlexecd) does not verify
that the connection is from a reserved port.

The basic setup is that you have a database server, and several other
client unix stations. You (root) are the only one who has
administrator authority on all the stations. Each client station has lots
of users on them, only some of which have database access. For each
client station that you want to be able to access the database server,
you add it to the hosts.equiv file on the database server.

So far, nothing out of the ordinary. Since (in my case) the network
between all the stations is secure there is no security issue at this point.

Since the informix daemon process (sqlexecd) does not verify the source
port, this results in a major security problem, since the ONLY way of
trusting a socket connection from a remote host is if you trust the
remote host, AND the connection comes from a secure port.

Hard Method:
------------
Any user on a trusted host can (by learning the informix sqlexecd
protocol, or replaying a previously captured conversation from another
copy of informix software) establish a connection to the database server
AS -ANY- userid.

Easy Method:
------------
Any user can run a rinetd type of relay on a trusted host that relays
the connection from the trusted host to the database server. After doing
this, anyone from any host on the internet can use their own personal
copy of informix and open a connection to the trusted host, as if it were
the real database server. The connection will then be passed on through,
and the remote sqlexecd will accept what it is told without checking the
remote userid.

A similar problem occurs using .rhosts instead of hosts.equiv. When using
rhosts, assuming the entry "host1.domain anything" in 'joe's account, any
user on host1.domain can connect to the database server as joe. The value
of 'anything' doesn't matter.

In summary, when you add a trusted host - the BSD r-tools are only giving
access from one userid to the matching userid. The sqlexecd is giving
access from ANY userid to ANY other userid.

NOTE: In all of the above (trusted host == host in /etc/hosts.equiv)

    b) How would you envision it being used in an attack scenario:

Case 1:
-------
A local user decides they want to make a change to a database they have
no permissions to modify.

Step 1: Start rinetd on a trusted host (HOST-T) that connects to the database
        server host (HOST-DB)
Step 2: Install informix on another unix host anywhere (HOST-C)
Step 3: Create a userid on HOST-C that matches a userid on HOST-DB that
        has database privileges, i.e. 'informix', the DBA userid.
Step 4: Log in as 'informix' on HOST-C
Step 5: Point Informix software on HOST-C at HOST-T, and open a connection

Voila. You now have a SQL connection to the database server as
'informix', and can do whatever you want.

Case 2:
-------
Local user grants access using rinetd type facility to the entire database
server to other users outside the organization, even though the local
user only has minimal or no database privileges.

Case 3:
-------
Current employee leaves (fired/quits/etc.)
Before leaving, they put in a rinetd service on a trusted host.
After leaving, they can still access the databases

To your knowledge is the vulnerability currently being exploited?
- - ----------------------------------------------------------------
        [yes/no]

        I am not aware of any specific break-ins, however, any site that
is USING the network functionality of informix is actually using the hole
without realizing it.

If there is an exploitation script available, please include it here.
- - --------------------------------------------------------------------

Do you know what systems and/or configurations are vulnerable?
- - -------------------------------------------------------------
        [yes/no]  (If yes, please list them below)

These are the only systems I have Informix for that I can test.

        System          : HP-UX
        OS version      : 9.x, 10.x
        Verified/Guessed: HP-UX 9.x, 10.x

I have tested and verified that the problem occurs with the following
connections:

        5.x client -> 5.x server (Online)
        7.x client -> 7.x server (Informix-SE)
        7.x client -> 5.x server (Online)

Are you aware of any workarounds and/or fixes for this vulnerability?
- - --------------------------------------------------------------------
        [yes/no] (If you have a workaround or are aware of patches
              please include the information here.)

The problem is that sqlexecd is not verifying the source port. There are
two possible fixes:

1) If client software will automatically try a <1024 source port if it is
setuid, then just change sqlexecd to require a source port <1024. (As is
pretty much mandated by saying that you're doing BSD security)

2. Alternatively, sqlexecd could attempt to verify the remote user using
ident. Since you've already stated that root on the remote host is
trusted, this isn't a security problem.

OTHER INFORMATION
===========================================================================
Is there anything else you would like to tell us?

Any site that has network access open for an informix database using
hosts.equiv is vulnerable to any of their users opening a connection and
making ANY database change they wish.

This hole also leads to many others due to the potential for using the
UNLOAD TO "file" sql query of the database server.

-----------------------------------------------------------------------

Sure, I'd be happy to explain it.

First, a short explanation of BSD ruserok() security mechanisms. First
requirement is that you trust the network between the two computers.
(i.e. two ports on a switch, an internal network that you have complete
control over, etc.), or even a network hooked to the internet, provided
that the two hosts have a trusted network between them, and that you have
a reasonable router configuration (i.e. protect against spoofing)

Second, you trust root on both machines.

With that, since unix won't let non-root users (or not setuid-root) users
bind to ports less than 1024, you know that if you receive a connection
from a trusted host, and it's from a port less than 1024 then you can
trust that either root or a root authorized process initiated the
connection. Once that is established, you can trust the information that
is sent over the connection, i.e. the userid

Based on documentation in informix manuals, people often configure their
trusted hosts to be able to access the database via these mechanisms,
putting the hosts in hosts.equiv or having individual users set up
.rhosts files.

Heres where the problem is. The Informix sqlexecd's do not bother to
check the source port to make sure it is less than 1024. This gives up
ALL the security in the ruserok() mechanism. Since anyone can open the
connection at that point and send whatever data they want. (i.e. a
different userid than who they really are)

At this point, the only security remaining is the lack of knowledge of
the informix database communications protocol.

Now, the 5-minute-give-me-full-access-to-everything exploit:

        1. Get a userid on any trusted machine - i.e. you are a current/ex
employee, a hole in a cgi script, whatever
        2. Compile a program like 'rinetd' - basically it
accepts inbound tcp connections on one port, and opens a connection to
another host on the same or different port. (This is as simple as a 20-30
line c program.) This program can be run by any normal user and requires
no special privileges.
        3. Configure the program to accept connections on port 37843 or
some other arbitrary port number, and tell them to connect to port 1525
(or whatever you have in your services/sqlhosts file) on your database
server. Run the program.

        4. Go to ANY other host on the internet, get a copy of informix,
or Info-Maker, or pretty much anything that can talk to an informix
database server.
        5. Tell the software to open up a connection to the database
server running at port 37843 on the host where you ran the rinetd. Claim
to be whoever you want to be. The database server will log you in without
a password.

------

If you use hosts.equiv, all userids on the database server are
vulnerable. If you use .rhosts, any user that uses .rhosts is vulnerable
- no matter what userids they list in the file.

Believe it or not, I ran across this completely by accident. I was doing
some diagnostics and working on some problems I was having building some
applications with a particular version of the informix libraries, and
noticed that all of the informix tools were not installed setuid-informix
or setuid-root. I was confused for a moment there thinking how could they
possibly be using the ruserok() type security mechanism if the tools were
setuid root.

The only way I can find to secure this is to completely remove ALL remote
database access to informix (shut off sqlexecd), or be 100% certain that no
hosts.equiv access is set up and that no user has any .rhosts file in
their account.

I can demonstrate this connecting from a 7.10 client to a 5.x server, a
7.10 client to a 7.10 server, and a 5.x client to a 5.x server. In
addition, I believe I can demonstrate it with any InfoMaker or ODBC
(PC/Windows/Mac) informix client to either a 7.10 or 5.x server.

If you need any more details, or would like a demonstration of this
complete lack of security, please let me know. If you get any real
response from informix on this, or whatever, let me know. I'd be
interested in how it turns out, or helping out in any way. I do have
correspondence with the CERT people regarding this if you are interested
in having a look at it.

-- Nathan

> Hi, earlier this year you posted the message below to BUGTRAQ.  It talks
> about a major security hole on the informix 5 and 7 servers... I would
> greatly appreciate any additional information you can provide.. in
> particular how you found this out and how to duplicate it (so that I can
> show that this is the case)
>
> Date:         Fri, 15 May 1998 12:54:22 -0500
> Reply-To: Nathan Neulinger <nneul () UMR EDU>
> From: Nathan Neulinger <nneul () UMR EDU>
> Subject:      Re: security holes, notification protocols, and a clarification
> To: BUGTRAQ () NETSPACE ORG
>
> On Thu, May 14, 1998 at 06:29:41PM +0000, Michael Tiemann wrote:
> > I have been informed that this list exists to serve users who have
> > become disenchanted with CERT and "the establishment," and hence the
> > readership values _immediate_ disclosure of _all_ security-related
> > problems, and I have no complaint about that, either.
>
> I'd certainly agree with that. I haven't been on this list for long, but a
> while (months ago) back I reported a very serious problem with Informix
> database servers to CERT, and basically never heard squat back. Sure, they
> said they were looking into it, but nothing ever got done.
>
> The security hole is severe enough to basically null out any security
> database/table permissions that you use.
>
> The problem boiled down to - they are using BSD ruserok() type security
> for their remote database access for other unix hosts, but they don't
> bother to check the source port. So, if you enable another host (that you
> rightly trust on a secure network) to connect to your database server,
> you have unwittingly given ALL users on that host access to ALL users in
> the database server. What's worse, within a couple of minutes, a user on
> the remote machine can run a program (rinetd for example) that will allow
> ANYONE from ANYWHERE to connect to the database as any user.
>
> The problem definately exists in the 5.x and 7.x series of servers, both
> SE and Online. I am not sure about their newer workgroup or universal
> servers.
>
> -- Nathan
>
> ------------------------------------------------------------
> Nathan Neulinger                       EMail:  nneul () umr edu
> University of Missouri - Rolla         Phone: (573) 341-4841
> Computing Services                       Fax: (573) 341-4216
>
>
> ---End of forwarded mail from Nathan Neulinger <nneul () UMR EDU>