Vulnerability

    yppasswd

Affected

    Solaris 2.6, 7, 8

Description

    Jose Nazario and  Matt Fearnow posted following.  Credits  goes to
    'metaray' for findings.  Please note  that this  is  a preliminary
    characterization of the Solaris yppassword buffer overflow.   This
    version is available  to provide at  least some information  about
    it.  Please check back over  the next few days as the  information
    is made more complete.

    A buffer overflow  exploit (for the  SPARC architecture) has  been
    found in the wild which takes advantage of an unchecked buffer  in
    the 'yppasswd' service on Solaris 2.6, 7 machines.  The  Intel/x86
    version of Solaris  2.6 and 7  may be vulnerable  but has not  yet
    been tested.

    To check  your system  for vulnerability,  use "rpcinfo  -p | grep
    100009" or you  can use "ps  -ef | grep  yppasswdd".  If  you  see
    something, your system might be vulnerable to this exploit.   Note
    that  Solaris  can  provide  a  "100009"  RPC  service  either via
    rpc.yppasswdd, or  (if the  system is  an NIS+  server running  in
    NIS-Compatibility mode) via rpc.nispasswdd.   When the exploit  is
    run against an rpc.nispasswdd, there's a syslog

        rpc.nispasswdd[###]: received yp password update request
        from (various binary data followed by a shell command)

    and  rpc.nispasswdd  continues  running.   Don't  know  for   sure
    whether rpc.nispasswdd can be  vulnerable to this exploit,  but we
    saw no vulnerability in any of tests (which were on Solaris 7).

    Exploit log message:

        May  9 13:56:56 victim-system yppasswdd[191]: yppasswdd: user
        @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@L
        @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
        @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
        @@@@@@@@@@@@@@@@@P"
        `"?-"?-"?-"? ; /bin/sh-c echo 'rje stream tcp nowait root /bin/sh sh
        -i'>z;/usr/sbin/inetd -s z;rm z;: does not exist

    Symptoms: two inetds running:

        victim-system:# ps -ef | grep inetd
        root   209     1  0   Apr 30 ?        0:18 /usr/sbin/inetd -s -t
        root  8297     1  0 13:56:56 ?        0:00 /usr/sbin/inetd -s z

    Effect: root shell on port 77/TCP

        she-ra:$ telnet victim-system rje
        Trying 192.168.10.5...
        Connected to victim-system.example.com.
        Escape character is '^]'.
        #

    While running the code against a "non vulnerable" Solaris  system,
    Snort picks up the following:

        May 10 20:52:33 macew snort[30824]: IDS19/portmap-request-amountd:
        192.168.4.38:654 -> 192.168.12.30:111

        May 10 20:52:33 macew snort[30824]: IDS19/portmap-request-amountd:
        192.168.4.38:654 -> 192.168.12.30:111

        May 10 20:52:33 macew snort[30824]: IDS19/portmap-request-amountd:
        192.168.4.38:654 -> 192.168.12.30:111

    The following is the snort  rule from whitehats, that picked  this
    up:

        alert UDP $EXTERNAL any -> $INTERNAL 111 (msg:
        "IDS19/portmap-request-autofsd"; rpc: 10099,*,*;)

    The publicly available exploit titled "rpc.yppasswdd SPARC  remote
    r000t  mray/metaray  04/01"  also  can  be  used  for  remote root
    compromise of Solaris 8 systems.

Solution

    The best  solution is  to firewall  your boxe(s)  that are running
    NIS from  the internet.   However this  will not  stop the insider
    attack.

    Sun has not release an official patch for this yet.  A  workaround
    1) would be to turn off yppasswdd.  This is around line 133 or  so
    in /usr/lib/netsvc/yp/ypstart.   Just comment  it out.   The  hack
    doesn't appear to  work if yppassword  is disabled with  NIS still
    running.   Please note  in doing  this, yppassword  is not running
    and users cannot change their password.

    Another work around 2) is if  you still need to run yppassword  is
    to do the following:

        set noexec_user_stack = 1
        set noexec_user_stack_log = 1
        in /etc/system (after a reboot of course)

    Of course a different exploit could work around that but hopefully
    this  will  permit  people  to  use  yppasswd  until  a  patch  is
    forthcoming.  This step has not been tested yet.

    Kukuk's rpc.yppasswdd builds without a great deal of wrestling  on
    Solaris 2.6.  There was one undef function, probably svc_getcaller
    but  it's  only  used  in  a  log  message,  so  it's easy to just
    eliminate.  This  could conceivably be  a more complete  temporary
    solution than setting up  noexec_user_stack (though both might  be
    best).