Date: Wed, 22 Dec 1999 10:07:33 MST
From: Brock Tellier <[email protected]>
To: [email protected]Subject: Solaris 2.7 dmispd local/remote problems
Greetings,
OVERVIEW
Several holes in the Solaris 2.7 SPARC/x86 dmispd daemon will allow
malicious users to do various DoS attacks and probably more.
BACKGROUND
I've only tested 2.7 with the latest patches as of this writing.
dmispd is the "DMI service provider".
I would appreciate if someone who knows about the workings of DMI would
enlighten me on what it's general purpose is. The man pages are appropriately
vague, so I'm not quite sure how it works. The fact that any remote user can
install a component into this database worries me a bit, but I don't know
enough about it to be able to say exactly what the impact of this could be.
I would recommend that some bugtraq solaris people who have a bit
more hands-on knowledge of the DMI subsystem take a serious look at
it's security. We all know Sun's reputation for daemon security
and, on top of this, I've already established at least one buffer
overflow in this particular service. There are several other
daemons which interact with dmispd as well, including snmpXdmid.
This program does all sorts of file i/o and UDP communication with
dmispd so I wouldn't be at all suprised to hear of some insecure
conditions there.
i.e. The vulnerabilities shown below are probably only the tip of
the iceberg.
DETAILS
Vuln #1 - local/remote users can use all /var disk space
By using "dmi_cmd", any user on any other Solaris machine (or
anyone who cares to port dmi_cmd) can use the "dmi_cmd -CI sp.mif"
command to add the sp.mif files to the /var/dmi/db database. A
user can repeat this process again and again until all of /var's
(or wherever the conf file is placing these files) disk space has
been used up. sp.mif appears to be installed by default and no
user authentication is done. An attack of this sort could be a
prelude to another, more serious attack, since most of Solaris's
system logs reside on /var. The interaction with dmispd does not
appear to be logged in any way.
Vuln #2 - local/remote users can crash the dmispd daemon
By using the same "dmi_cmd -CI" command, users can specify their
own file to add. If this file contains enough bites on the first
line, we can cause the daemon to segfault and crash. We can do
this using the reverse directory transversal problem as shown:
# any more than 1024 characters in here and dmispd reports an error
# and exit()'s without segfaulting.
echo `perl -e "print 'A' x 1000"` > /usr/home/btellier/my.mif
dmi_cmd -CI ../../../usr/home/btellier/my.mif
The client hangs, then reports an error. The daemon has segfaulted
and died. I've been able to overwrite ONLY the %o4 register and
nothing more. In addition to this, it seems that the daemon will
only accept regular letters/numbers/symbols and all other
characters are discarded, which greatly reduces our chances of
making this exploit anything more than a DoS.
I've tried specifying ../../../etc/shadow and other files to see if
they are written to the /var/dmi/db database, but dmispd parses the
files for correct format and reports an error if they are not what
was expected.
Brock Tellier
UNIX Systems Administrator
Chicago, IL, USA
[email protected]
____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1
