Note: This is an archival copy of Security Sun Alert 200714 as previously published on http://sunsolve.sun.com.|
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1000566.1.
Solaris 10 Operating System
Date of Workaround Release
Date of Resolved Release
A local or remote unprivileged user may be able to disable the snmpd(1M) daemon causing a Denial of Service (DoS) of the SNMP service.
This issue is also referenced at the following URL:
This issue can occur in the following releases:
Note 1: Solaris 8 and Solaris 9 do not ship with the Net-SNMP software and thus are not impacted by this issue.
Note 2: The Net-SNMP software was not bundled with Solaris prior to Solaris 10. However, customers who have built and/or installed a vulnerable version of Net-SNMP on any version of Solaris are at risk. See the Net-SNMP web site to download the latest version of Net-SNMP which addresses these issues.
Note 3: The Solaris 10 patches which address this vulnerability do not increment the version of Net-SNMP. The version of Net-SNMP supplied with the patches will still be reported as 5.0.9.
This issue only affects systems which have the SUNWsmagt package installed. To determine if the SUNWsmagt package is installed on the system, the following command can be used:
$ pkginfo -l SUNWsmagt PKGINST: SUNWsmagt NAME: System Management Agent files and libraries CATEGORY: system VERSION: 1.0,REV=2005.01.08.05.16
Note: Only Net-SNMP 5.0.9 and earlier listening on TCP:161 (as delivered by SUNWsmagt)is affected by this issue.
To confirm the version of Net-SNMP installed on the system, the following command can be used:
$ /usr/sfw/sbin/snmpd -v NET-SNMP version: 5.0.9 Web: http://www.net-snmp.org/ Email: firstname.lastname@example.org
If the version reported is 5.0.9 or earlier, and the above patch is not installed when testing the version of snmpd(1M) that is shipped with Solaris, then the described issue may occur.
Note: The Net-SNMP distribution of snmpd(1M) by default listens only for UDP requests. To confirm whether "/usr/sfw/sbin/snmpd" is listening on port 161 for TCP requests, one can telnet to port 161 on the system in question:
$ telnet <hostname/localhost> 161 Trying x.x.x.x... Connected to .. Escape character is '^]'. Connection to . closed by foreign host.
If a connection can be made to port 161 then it is likely that the snmp(1M) daemon is listening for TCP requests.
To further verify that it is not a service other than snmpd(1M):
$ grep 161 /etc/services
The above command should only return the following:
snmpd 161/udp snmp # SMA snmp daemon
snmpd 161/tcp snmp # SMA snmp daemon
Note: Even if TCP is not listed for snmpd(1M) in /etc/services, it is possible that snmpd(1M) has been passed arguments at startup causing it to listen for tcp.
If the described issue occurs, high utilization of system resources by snmpd(1), as viewed by a utility such as prstat(1M) may occur.
To work around the described issue, disable snmpd(1M) from listening to TCP requests on port 161 (UDP is unaffected).
To Disable snmpd from listing to TCP requests on port 161, pass the following argument to snmpd(1M) at startup:
For example :
To Verify snmpd(1M) is no longer listening for TCP requests on port 161:
$ telnet <hostname/localhost> 161 telnet: Unable to connect to remote host: Connection refused
This issue is addressed in the following releases:
This solution has no attachment