Type packetstorm
Reporter Brock Tellier
Modified 1999-12-22T00:00:00


Several holes in the Solaris 2.7 SPARC/x86 dmispd daemon will allow malicious users to do various DoS attacks and probably more.  
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.  
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