Re: Gaping security hole? (network db connections)

Michael Segel <"MailerDaemon"@[127.0.0.1]> wrote: > > The sqlexec process on the client is running as 'joeuser'. Anything that > > a process running as 'joeuser' can do, so can a process running as > > 'freduser'. > > > > The only way .rhosts/hosts.equiv works is that remsh/rlogin/rcp are all > > setuid root, and open a connection with the source port being a secure > > port. The reason for that is, only root can open a connection on a secure > > port, hence, if a connection comes from a secure port, it has to have > > been made by root, or a root authorized process. Since the remote host is > > trusted, that means we can trust root on that host to tell us who the > > user really is. > > > Do you really want to trust root on another system? > ;-) > (Now you see the point.) Yes, if both of the machines are MY machines. i.e. I have several machines on a private network, all of which only I have root on. ALl of them need to access the database server. Wiring a password is not acceptable, so I'm using the hosts.equiv mechanism. I would understand your point if I were talking about joe-schmoes machine on some other network. I'd have to be insane to trust that kind of connection with .rhosts/hosts.equiv. > > As near as I can tell, there is nothing that would prevent me from > > replaying a sqlexec connection, and just changing the userid. I'm sure > > that there are other fields that would need to be matched up (i.e. > > length, etc.), but that can be done with a little work. > > > Well, you would first have to capture a connection to replay it. > However, there are other attacks which take advantage of > .rhosts and hosts.equiv files. The point is that you wouldn't even have to replay a particular connection. You could just go learn what the connection should look like from another database server, and then apply that knowledge to this one. (I.e. I could make my own copy of informix, install it somewhere else, and look at what a connection looks like, and then send that same data to our central server. The problem here isn't the usual security problems with BSD .rhosts / hosts.equiv mechanism. We've accepted those. And if it were only that, this wouldn't be a problem. > I'd give you a list of recommended reading on security, but > my books are in Chicago, and I'm stuck in Cleveland. :-) I'm aware of the security problems with .rhosts/hosts.equiv, but the problem here is that even the limited security being provided by the ruserok() mechanism IS NOT being employed by Informix's sqlexecd. As near as I can tell, the informix security boils down to the following: A connection is opened from any port on CLIENT to the sqlexec port on SERVER. The client tells the server "I am FRED, connect to database". At this point, the normal ruserok() mechanism would: 1. Check hosts.equiv and .rhosts to see if anything matches 2. Check to make sure connection is from secure port, otherwise cannot trust data sent. Sqlexecd doesn't appear to do the second. It just arbitrarily says: This is from a trusted host, so it must be fred since that is what the remote host told me. ------------ Unlike the BSD ruserok() mechanism which is saying: "Do you trust root on this remote host?". The informix mechanism is saying "Do you trust ALL USERS on this remote host?" Do you see the difference? With the ruserok() mechanism, you have to trust: 1. root on the remote host 2. the network in between two remote host and the server In most local server environments, both of the above are reasonable. In our case, the two machines are on a switch. With sqlexecd, you have to trust 1. EVERY user that has login access to the machine 2. The network ... By trust I mean that you are saying that the user is allowed to make ANY query against the database server. -- Nathan ------------------------------------------------------------ Nathan Neulinger Univ. of Missouri - Rolla EMail: nneul@umr.edu Computer Center WWW: http://www.umr.edu/~nneul SysAdmin: rollanet.org