[plug] Any machine running Solaris 2.6, 7, or 8....
Kai
vk6ksj at siwa.com.au
Sat Mar 31 12:44:11 WST 2001
sorry for posting a forward but I thought you guys might want to know
this.
CERT Advisory wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> CERT Advisory CA-2001-05 Exploitation of snmpXdmid
>
> Original release date: March 30, 2001
> Source: CERT/CC
>
> A complete revision history can be found at the end of this file.
>
> Systems Affected
>
> Any machine running Solaris 2.6, 7, or 8 with snmpXdmid installed and
> enabled. snmpXdmid is installed and enabled by default on these
> systems.
>
> Overview
>
> The CERT/CC has received numerous reports indicating that a
> vulnerability in snmpXdmid is being actively exploited. Exploitation
> of this vulnerability allows an intruder to gain privileged (root)
> access to the system.
>
> I. Description
>
> The SNMP to DMI mapper daemon (snmpXdmid) translates Simple Network
> Management Protocol (SNMP) events to Desktop Management Interface
> (DMI) indications and vice-versa. Both protocols serve a similar
> purpose, and the translation daemon allows users to manage devices
> using either protocol. The snmpXdmi daemon registers itself with the
> snmpdx and dmid daemons, translating and forwarding requests from one
> daemon to the other.
>
> snmpXdmid contains a buffer overflow in the code for translating DMI
> indications to SNMP events. This buffer overflow is exploitable by
> local or remote intruders to gain root privileges.
>
> More information about this vulnerability can be found in
>
> CERT/CC Vulnerability Note VU#648304
> Sun Solaris DMI to SNMP mapper daemon snmpXdmid contains buffer overflow
> http://www.kb.cert.org/vuls/id/648304
>
> Affected sites have reported discovering the following things on
> compromised systems:
>
> * Evidence of extensive scanning for RPC services (port
> 111/{udp,tcp}) with explicit requests for the snmpXdmid service
> port prior to the exploit attempt
> * A core file from snmpXdmid on the / partition
> * An additional copy of inetd running (possibly using /tmp/bob as a
> configuration file)
> * A root-privileged telnet backdoor installed and listening on port
> 2766 (although any port could be used)
> * An SSH backdoor installed and listening on port 47018 (although
> any port could be used)
> * An IRC proxy installed as /var/lp/lpacct/lpacct and listening on
> port 6668
> * A sniffer installed as /usr/lib/lpset
> * Logs altered to hide evidence of the compromise
> * System binaries replaced by a rootkit installed in /dev/pts/01/
> and /dev/pts/01/bin (the versions of 'ls' and 'find' installed
> by the rootkit do not show these directories)
>
> The contents of /dev/pts/01 may include
> + bin
> + crypt
> + idsol
> + patcher
> + su-backup
> + utime
> + bnclp
> + idrun
> + l3
> + pg
> + urklogin
>
> The contents of /dev/pts/01/bin may include
> + du
> + find
> + ls
> + netstat
> + passwd
> + ping
> + psr
> + sparcv7
> + su
>
> Note: Since 'ps' and 'netstat' are both replaced by the rootkit, they
> will not show these processes or open ports. However, you may find
> that '/usr/ucb/ps' is still intact, and will show the additional
> processes.
>
> II. Impact
>
> A local or remote user that is able to send packets to the snmpXdmi
> daemon on a system may gain root privileges.
>
> III. Solution
>
> * Apply a patch from Sun when it is available
> Sun has been notified of this issue and is actively working on
> patches to address the problem. This advisory will be updated when
> patches are available.
>
> * Disable snmpXdmi
> Until patches are available, sites that do not use both SNMP and
> DMI are stongly encouraged to disable snmpXdmid.
>
> One way to accomplish this is to issue the following commands (as
> root):
>
> 1. Prevent the daemon from starting up upon reboot
> mv /etc/rc3.d/SXXdmi /etc/rc3.d/KXXdmi
> 2. Killing the currently running daemon
> /etc/init.d/init.dmi stop`
> 3. Verify that the daemon is no longer active
> ps -ef | grep dmi
> 4. As an additional measure, you may wish to make the daemon
> non-executable
> chmod 000 /usr/lib/dmi/snmpXdmid
>
> * Restrict access to snmpXdmi and other RPC services
> For sites that require the functionality of snmpXdmi or other RPC
> services, local IP filtering rules that prevent hosts other than
> localhost from connecting to the daemon may mitigate the risks
> associated with running the daemon. Sun RPC services are advertised on
> port 111/{tcp,udp}. The snmpXdmid RPC service id is 100249; use
> 'rpcinfo -p' to list local site port bindings:
>
> # rpcinfo -p | grep 100249
> 100249 1 udp 32785
> 100249 1 tcp 32786
>
> Note that site-specific port binding will vary.
>
> Appendix A. - Vendor Information
>
> Sun Microsystems
>
> We can confirm that this affects all versions of Solaris that ship the
> SNMP to DMI mapper daemon, that is, Solaris 2.6, 7 and 8. To the best
> of my understanding from discussion with the engineering group working
> on this, for sites which do use DMI (dmispd) and the mapper
> (snmpXdmid), there are no workarounds.
>
> ______________________________________________________________________
>
> The CERT/CC thanks Job de Haas (job at itsx.com) of ITSX BV Amsterdam,
> The Netherlands (http://www.itsx.com) for reporting this vulnerability
> to the CERT/CC.
> ______________________________________________________________________
>
> This document was written by Brian B. King with significant
> contributions by Jeff Havrilla, and Cory F. Cohen.
> ______________________________________________________________________
>
> This document is available from:
> http://www.cert.org/advisories/CA-2001-05.html
> ______________________________________________________________________
>
> CERT/CC Contact Information
>
> Email: cert at cert.org
> Phone: +1 412-268-7090 (24-hour hotline)
> Fax: +1 412-268-6989
> Postal address:
> CERT Coordination Center
> Software Engineering Institute
> Carnegie Mellon University
> Pittsburgh PA 15213-3890
> U.S.A.
>
> CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4)
> Monday through Friday; they are on call for emergencies during other
> hours, on U.S. holidays, and on weekends.
>
> Using encryption
>
> We strongly urge you to encrypt sensitive information sent by email.
> Our public PGP key is available from
>
> http://www.cert.org/CERT_PGP.key
>
> If you prefer to use DES, please call the CERT hotline for more
> information.
>
> Getting security information
>
> CERT publications and other security information are available from
> our web site
>
> http://www.cert.org/
>
> To subscribe to the CERT mailing list for advisories and bulletins,
> send email to majordomo at cert.org. Please include in the body of your
> message
>
> subscribe cert-advisory
>
> * "CERT" and "CERT Coordination Center" are registered in the U.S.
> Patent and Trademark Office.
> ______________________________________________________________________
>
> NO WARRANTY
> Any material furnished by Carnegie Mellon University and the Software
> Engineering Institute is furnished on an "as is" basis. Carnegie
> Mellon University makes no warranties of any kind, either expressed or
> implied as to any matter including, but not limited to, warranty of
> fitness for a particular purpose or merchantability, exclusivity or
> results obtained from use of the material. Carnegie Mellon University
> does not make any warranty of any kind with respect to freedom from
> patent, trademark, or copyright infringement.
> _________________________________________________________________
>
> Conditions for use, disclaimers, and sponsorship information
>
> Copyright 2001 Carnegie Mellon University.
>
> Revision History
> March 30, 2001: Initial release
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 5.0i for non-commercial use
> Charset: noconv
>
> iQCVAwUBOsT85wYcfu8gsZJZAQE+jAP+NzhcGlYONhR3O62XsiK5r0pgvCTV8ka8
> 3SCaNE4BsIbdjIOmcyjsqa3EF8FSpb4XM4B9ttN0SorHaHua/9f74+I0ElR4s3XI
> njCOlVFQA8bhAeITiUmsE7jX7qkRZC/cNPzDMgSrEIZROxW5MctT6V9F3QHJ16pj
> wW5aPw2rHck=
> =t6h8
> -----END PGP SIGNATURE-----
More information about the plug
mailing list