> > I have verified a problem with "/" permission on AIX versions: > 3.2.5.0 , 4.1.4.0 4.2.1.0, and I guess on every version of AIX. > > The problem is that the owner of "/" is user bin instead of user root. > > Which means that if one manages to get "bin" permissions he might get > root permissions by: > > > mv -r /etc /etc.old > > cp -r /etc.old /etc > > echo "yarony::0:0:Yaron:/:/bin/tcsh">> /etc/passwd > or something like that. > > And to get bin permissions one should exploit the current version of > sendmail or use mis-configured NFS server, or exploit a buffer overflow in > /usr/bin/nslookup (the only suid bin in AIX ,and it suid only in AIX 4.1.5) > > I have informed AIX about it a month ago. They told me that it doesn't > look like this is going to be changed. The reason was that all my ideas > about how to get bin permissions were by exploiting mis-configured system. > HP-UX (all versions) has a similar problem. / is owned by root:root, but subdirectories, such as /etc, are owned by bin:bin, as are most system binaries. They don't seem too eager to fix it either. As shipped, I believe there is only one setuid bin item -- kermit, why it is setuid bin, I have no clue. My fix is to remove the setuid from kermit, and do a find for anything owned by bin and chown it to root. Other than needing to fix one or two things in /usr/lbin (making permissions on identd and maybe fingerd less strict so that it can still run as "bin") everything works fine when you do this. I would at least like someone to have to break root (or something running as root) to break into my systems, there are enough root holes without adding all the "any user but root" holes to be simple stepping stones to root. Even Irix, the most insecure commercial Unix out there, got these simple ownership issues correct. Wonder what's wrong at HP and IBM that their security guys can't get this change through? At least, I assume IBM's security guys would like to make this fix, I know HP's security guys do but for a long time they've been "studying" a long list of permissions problems a couple of us here the University of Iowa sent them a couple years ago. My impression was that the security guys would like to get these changes made but its the usual variety of reasons when you have different managers responsible for different parts of the OS. And also probably a lack of customers telling their sales reps these sorts of security issues are important to them, and making sure their reps tell their bosses and so on. We've made sure our rep communicated this, but most customers are probably unaware, and those that are can fix these problems themselves with little effort and don't bother to complain except to each other :) -- Douglas Siebert Director of Computing Facilities douglas-siebertat_private Division of Mathematical Sciences, U of Iowa A fool of sufficient magnitude can be found to overcome any foolproof system.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:56:22 PDT