Bugtraq mailing list archives

Solaris 2.7 dmispd local/remote problems


From: btellier () USA NET (Brock Tellier)
Date: Wed, 22 Dec 1999 10:07:33 MST


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
btellier () usa net

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1


Current thread: