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: http://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: http://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