Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

AIX / HP-UX : "/" is owned by bin.bin (fwd)

33 views
Skip to first unread message

John Ladwig

unread,
Jun 2, 1998, 3:00:00 AM6/2/98
to

[ This is bad. Note that on HP-UX fingerd (known to have a history of
overrunnable buffers) runs as bin. Sitting on the network,
listening to packets from just about anywhere.

If someone has the iterated list of what perms to change to get
around this on either AIX or HP-UX (please include version numbers),
I'd love to see it, and will share the information submitted

-jml
]

Forwarded message:

Date: Mon, 1 Jun 1998 17:24:26 -0500
From: dsie...@ICAEN.UIOWA.EDU
Organization: Iowa Computer Aided Engineering Network, University of Iowa
Subject: Re: AIX : "/" is owned by bin.bin
X-To: yar...@yarony.il.eu.org
To: BUG...@NETSPACE.ORG
In-Reply-To: <Pine.LNX.3.96.980529...@vipe.technion.ac.il>
from "Yaron Yanay" at Jun 1, 98 09:13:29 pm

>
> 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...@uiowa.edu Division of Mathematical Sciences, U of Iowa

A fool of sufficient magnitude can be found to overcome any foolproof system.

0 new messages