Product: Dell OpenManage Web Server 3.4.0 and others assumed vulnerable. Confirmed 3.7.0 is Vulnerable.
Vulnerability: Pre-Authentication Heap Based Buffer Overflow
Severity: High Risk
Status: Vendor notified but security contact on vacation. Support also contacted but
believed our issue is related to our hard drive being full.
Update March 3rd 2003: Dell has silently released a patch which can be downloaded from:
https://support.dell.com/filelib/download.aspx?FileID=96563&c=us&l=en&s=DHS&Category=36&OS=WNT5&OSL=EN&SvcTag=&SysID=PWE_FOS_XEO_6650&DeviceID=2954&Type=&ReleaseID=R74029

Description:
A buffer overflow vulnerability can be exploited remotely by an unauthenticated attacker
who can access the Dell OpenManage Server. By default Dell OpenManage listens on port 1311 TCP. 
By constructing a POST HTTP method with the hidden variable application= set to a long string,
the OM server attempts to open an ini file with our constructed string. This string is set to
omsa by default and when a login is attempted it tries to open the "application" variable directory.
By default the OCSGetOEMINIPathFile function tries to open C:\Program Files\Dell\OpenManage\omsa\oem.ini.
OCSGetOEMINIPathFile calls a heap allocation routine which only allocates 256 bytes. Since
this length is not checked anywhere we can overwrite the heap structures with massive amounts
of data.

Exploitation Problems:
Exploiting this issue to execute code was out of my reach. Since this is the first Heap based
overflow I've encountered my expertise was not advanced enough to cause this vulnerability
to execute code. First our string is unicoded and copied in memory to multiple locations.
At first it seems as though this string is never unicoded, when looking at the string
after the exception we notice there are no null bytes between the characters. If we 
attempt to put in a character > 0x7f the unicode reveals itself and adds a secondary byte in the form of 
0xc2, 0x80 (for 0x80) 0xc2, 0x81 (for 0x81). For strings greater than 0xbe it then changes 
the secondary byte to 0xc3, 0x80 (for 0xbf). When looking for addresses to overwrite,
I personally was unable to identify anything that did not contain a byte over 0x7f. Technically
we can have a single byte over 0x7f but this could only be used for the first byte of the overwrite.
Or if we were able to identify an address or our string somewhere static in memory we could
technically use one of these characters. 
Other issues you will find when attempting to exploit this is the program crashes and reads
invalid areas or other weird execeptions occur when attaching with a debugger (ollydbg in my case).
This program uses a slew of Java/jvm functions and dll's which also causes problems. A lot
of the functions appear to be executing from the heap so it was very hard (for me) to track or find 
information about the functions because the addresses were dynamic.
Also I noticed every once in a while a reboot would cause the overwrite to happen in different areas.



Technical Details:
As I mentioned previously the overflow is due to:
094D8718   E8 53FAFFFF      CALL omacs32.OCSGetOEMINIPathFile
not checking the length of the application variable. A Heap Allocation routine is called
only allocating 256 bytes, so when we add string > 256 the heap structures begin to be
overwritten. 
Code:
094DE448   50               PUSH EAX
094DE449   6A 00            PUSH 0
094DE44B   FF35 48114F09    PUSH DWORD PTR DS:[94F1148] 
094DE451   FF15 F0A04E09    CALL DWORD PTR DS:[<&KERNEL32.HeapAlloc>>; ntdll.RtlAllocateHeap

Stack:
0C02F8E0   09520000  |hHeap = 09520000
0C02F8E4   00000000  |Flags = 0
0C02F8E8   00000100  \HeapSize = 100 (256.) ; hmm this doesn't look like enough to me...
0C02F8EC   09523D60  ASCII "111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111112222222222222222222222222222222222222"...
0C02F8F0   09524038  ASCII "ffffffffffffffffffffffgggggggggAAAABBBBippppppppppppppppppppppqqqqqqqqqq555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555"...
With a length of 10000 for the application string, I was able to gain control of two registers,
EAX and ECX. ECX is our 'where' and EAX contains our 'what.' 

In this case the exception occured at:
77FCC44A   8B4E 0C          MOV ECX,DWORD PTR DS:[ESI+C]
77FCC44D   898D 34FFFFFF    MOV DWORD PTR SS:[EBP-CC],ECX
77FCC453   8901             MOV DWORD PTR DS:[ECX],EAX  ; We control this
77FCC455   8948 04          MOV DWORD PTR DS:[EAX+4],ECX ; And obviously this.

After debugging *after* the exception I was unable to identify any function pointers or any addresses
that didn't contain a byte < 0x7f that was worth overwriting or useful in anyway. I can guaruntee
someone with more experience and better techniques *will* be able to take advantage of this flaw,
but currently I only have proof of concept DoS code which is well, Lame.

Comedy:
After using Dells "Support" page explaining I found a buffer overflow, the automated system
mistakenly thought I was talking about the buffer underrun issues with cdburners:

Dear Dell Customer,


Dell's e-mail software interprets your message as a request for help with a CDRW drive that will not "burn" 
to a CD blank.  This response document offers help with solving ""burn"" problems caused
by software conflicts or a defective Dell drive. It assumes that your drive can be opened and 
closed by pushing the button on its face plate and that it will read a CDROM program disk or play music
from a music CD.

So I respond:
Completely wrong, this is a security issue and should be looked at.
-wire

Then I finally get a person:
Wire,to resolve the issue please increase the virtul memory and
create more space in the hard disk using the disk cleanup option.Please
visit the following link to access the article that I wish to
forward you and perform the mentioned steps:

https://support.microsoft.com/default.aspx?scid=kb;en-us;257758&Product=win2000
The above link explains," FIX: "Limited Virtual Memory" Error
Message When You Start Your Computer"

Apparently to dell tech support security issue means "My hard drive ran out of space"
So I respond:
I'm sorry, this is a buffer overflow vulnerability, your product has a
security flaw that can allow any remote unauthenticated user to cause an
exception and possibly cause the Dell OpenManage web server to execute
remote code. This is not a problem with my installation it is a problem
with your product. Sorry I did not make this more clear to begin with.
-wire

And I get the response:
Dear Wire,

Thank you for contacting Dell eSupport and Services (ESS). We
appreciate the opportunity to assist you. I apologize for your
trouble and I assure you it is our hope that you have a positive
experience with our company.

Wire,I would like to add that within initial thirty days from
the invoice date, Dell Computer Corporation provides free basic
configuration and usage support for Dell factory-installed operating
system software, and factory-installed applications such as Microsoft
Word or Excel. To quickly resolve the issue you may please contact
Dell Technical Support at: 1-800-433-9005 and choose the software
support option.

So I give up on support and email security@dell.com (after waiting on hold for 45 minutes and giving up):
Subject: Out of Office AutoReply: Buffer Overflow Vulnerability in Dell
 OpenManage Web Server
To: wirepair@sh0dan.org

Thanks for choosing Dell. I will be out of the office  Feb, 18th, 2004
through  Feb 23th.   I will back on Feb. 24th.  I will return e-mail
messages as soon as possible upon my return.

Well isn't that something. Maybe they should consider hiring two security officers???
Could be worse, they could be like Citrix and try to charge me 400$ :D