Security hole?

I pulled the following off CERT. Anyone have comments? Katherine 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

<cutting> >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. This is just standard unix, you always without exception create a null hosts.equiv, chown it root and chmod 000. You then tweak your user add process and create the .rhosts in a similar way or revoke write permissions for the users home directory (my preferred option) -- Paul Watson # WF Software Ltd # You are only young once Tel: +44 1436 674729 # but you can be immature Fax: +44 1436 678693 # for ever www.wfsoftware.com #