Mailslot bug (MS06-035) vs. non-Mailslot bug(MS0?-???/CVE-2006-3942) This is the story of a yet unpatched bug which is not a 0-day. Time line: 2006-07-12 - MS06-035 Published by Microsoft [1] 2006-07-12 - "Windows Mailslot (MS06-035) DoS" module released to IMPACT customers 2006-07-13 - We realized (too late) that it was a different bug [2] 2006-07-14 - We got in touch with Microsoft 2006-07-19 - Public exploit released by cocoruder [3] (frankruder_at_hotmail.com) 2006-07-28 - ISS released their advisory [4] 2006-07-28 - Microsoft acknowledged the bug [5] 2006-08-14 - Today - We publish and advisory [10] and this email ---[ Intro ] Last month's patch Tuesday started with a nice challenge: A remotely exploitable code execution kernel bug for most Microsoft's OSes (most supported Windows). As my job is to write exploits, I jumped to that as soon as I could (which was latter than what I liked because we were closing a new version of our product). I got something working in a short time, sent it to QA to test and released before the end of the day... I was truly amazed... to only find out, a little bit later, that I had accidentally found a different (yet unpatched today) bug. In this pseudo-advisory I will describe the Details of this new bug, the process of how I [also] "discovered" it, and why I think it's not exploitable (only to be proved later by someone else that I'm a moron) ---[ MS06-035... I think ] For a long time I've been waiting for a remotely exploitable kernel bug to try to exploit. It was a tough challenge, at least for me, as I've never before worked on such a beast. I jumped immediatly to Microsoft's advisory's [1] "Vulnerability details" section to find what I expected: NOTHING. Just a general description, as in most advisories lately, which can't, in any way, be used to prove or disprove the existence of the bug, nor to decide how high in the priority list this patch should be put: "There is a remote code execution vulnerability in the Server driver that could allow an attacker who successfully exploited this vulnerability to take complete control of the affected system." [1] Uhm... if the information is not under "Vulnerability details", where may it be? I think I need to take even more English lessons, because I thought "details" meant "detalles", oh well... let's read all the advisory just in case... After reading Microsoft's advisory I continued with TippingPoint's [5] and Pedram Amini's blog [7] to happily find a few more details. Let me summarize what I knew then: . Mailslot ==> SMB . Kernel Heap overflow . Code execution is possible (why would Microsoft over-rate it?) . SRV.SYS (Server driver) . Port 445 (from advisory's Workarounds section) . First class mailslot (whatever it means) What do I know about Mailslots? the basics, probably a little bit more, but surely not enough. Let's see if Impacket [11] has something for Mailslots: $ cd Impacket-0.9.6.0 $ grep -i mailslot * $ grep -i mailslot */* $ grep -i mailslot */*/* $ grep -i mailslot */*/*/* grep: */*/*/*: No such file or directory ... mmmm... nothing... now what? After quickly sending Pedram an email to congratulate him and HD for their finding (and, of course, cry for some help), I sat down to read CIFS' specification [12] once again. I searched for the word "mailslot" to only find it in one section describing the format for Mailslot Write transactions. Nice! Lets try the fuzzing approach, lets create a Mailslot request with a lot of data! So I opened my Ethereal and my Python interpreter, booted up a VMware with Windows, went through the automatic "Win-R, cmd, ipconfig". Got VMware's IP address and continued typing: from impacket import smb s = smb.SMB('*SMBSERVER','10.0.1.44') s.login('','') tid = s.tree_connect_andx(r'\\*SMBSERVER\IPC$') s.send_trans(tid, '\x01\x00\x00\x00\x00\x00', r'\MAILSLOT\LANMAN', '', 'A'*1000) BOOM! The vmware crashed! What? Wait a second... At this point I thought "How stupid I am! I should have tested this before! just sending a big packet crashed it!" And I'm one of those who 5 years ago thought "first generation fuzzers are not going to find too many bugs any more"... stupid me! "Ok. Got a crash, it's a kernel bug... no, no, it's a remotely exploitable kernel heap overflow bug... it's quite unlikely I will be able to do anything better than a simple Denial of Service for quite some days. So I better focus on writing down the documentation. I will send right away a working version to QA so we can try to ship it today". Thought and done. Documentation written, typos fixed, some extra packets added just in case, QA approved it for "Early release" mode... "Nice! we tested it against most Windows VMWares we have, it crashed them all in the first try. And we shipped it all in a single day! I was not really expecting this, I'm more used to spending a few days per bug until I have a QA-approved shippable version" - "Hey Kelya! lets ship it! it's done, QA approved it!" (Kelya's my boss) - "Sure... Ok, it's shipped now. Have you tried against a patched box?" - "Nop... 'cmon, It's not my job to test MS' patches!" [8] [9] (thanks aazubel!) - "Oh well... let me see... My box is patched, throw it against it" - "Ok, going... (double-click), gone" - "Eh! wait a second... Got a crash and dump, let me see if the box's really patched" - "Yeah, it must be still unpatched, I'll try someone else's box" - ... - "I think we may have found something else... pass me the memory dump to debug it" And so the second part of the story begins. ---[ MS0?-??? - CVE-2006-3942 - the new bug ] - "Let's go home now. Tomorrow we'll verify it and talk to Ivan so he gets in touch with Microsoft about this new issue" - "Ok, I'll try to debug it and figure out what's going on" The new bug, as explained by ISS' advisory [3], is due to a NULL pointer dereference, and I firmly believe that it's not exploitable. As I said, I will quite likely be proved wrong on this, but I'll try to give my reasons: The crash is actually inside __imp___wcsnicmp, when the string "\\MAILSLOT" is compared to a NULL pointer. The following code, from ExecuteTransaction(), is where wcsnicmp() is called from. SRV.SYS:0002f487: push 9 SRV.SYS:0002f489: push "\\MAILSLOT" SRV.SYS:0002f48f: push dword ptr [eax+24h] <-- [eax+24] is NULL SRV.SYS:0002f492: call ds:__imp___wcsnicmp <-- Crash Inside (tm) SRV.SYS:0002f498: add esp, 0ch SRV.SYS:0002f49b: test eax, eax SRV.SYS:0002f49d: jnz loc_2f4aa SRV.SYS:0002f49f: push esi SRV.SYS:0002f4a0: call _MailslotTransaction@4 <-- not reached SRV.SYS:0002f4a5: jmp loc_20bf6 SRV.SYS:0002f4aa: Apparently, for some reason, our packet made [eax+24h] be NULL, which forced something like: wcsnicmp(0, "\\MAILSLOT", 9); Which obviously crashes. After some tests, I found out that the only thing that mattered here, is that no NUL should be sent after the "Mailslot name". And in fact, 'A'*1000 is not necessary, and the mailslot name doesn't really have to mean anythin. So, the following python script should still trigger the bug: ----- from impacket import smb s = smb.SMB('*SMBSERVER','10.0.1.44') s.login('','') tid = s.tree_connect_andx(r'\\*SMBSERVER\IPC$') s.send_trans(tid, '\x01\x00\x00\x00\x00\x00', 'cuchicuchi','','') ----- - "Kelya, Ivan: I'm pretty sure this is a different thing... it's not related to mailslots, it's not related to a buffer overflow, and apparently, it's not exploitable for code execution" - "Uhm... Ok, I'm getting in touch with MS to let them know. You should have tried it against a patched box before releasing." - "I know, but we were in Early Release mode, and we were too worried testing the exploit to stop and test if Microsoft's patch really worked." - "Take some time to see if it's exploitable or not, I'll talk to Microsoft" - "Sure! I have already started!" I believe this is not exploitable for code execution, and I know stating this is pretty much like putting a loaded gun in my mouth. My decision tree for that is: . Either it crashes in wcsnicmp(). In which case it's only a Denial of Service. . Or it doesn't crash in wcsnicmp(). . The string begins with "\\MAILSLOT", and it becomes a MailslotTransaction() where it may find another bug, but not this. . The string doesn't begin with "\\MAILSLOT", in which case ExecuteTransaction() returns with an error message. Evidently this is a new bug, not related to the processing of Mailslots and even not strictly related to Named Pipes [3], but to SMB_COM_TRANSACTION SMB messages (0x25) instead. So, we were in the process of talking to Microsoft when three interesting things happened: . A few customers sent us emails saying that we should get in touch with Microsoft because the exploit was too effective DoSsing patched and unpatched boxes. . An exploit for the very same bug was published, producing exactly the very same traffic as our exploit, bit by bit. And also falling in our same mistake of believing it was a Crash for MS06-035. [4] . ISS published an advisory a few days latter stating that, given the public exploit, they have independently discovered this new bug. [3] Microsoft publicly acknowledged the situation [6] after the advisory was published. All the information available says that they are currently working in a patch for the issue and that they have "...not observed or received any reports of the PoC being used to actively attack systems", what kind of confirms that the availability of Proof of Concept code has nothing to do with the bad people doing bad things. ---[ Concluding ] . Yes, there is a public exploit for a yet unpatched bug. This time it's just a DoS situation unless somebody proves me wrong (which is simpler than proving I'm right). . No, even when there's a public exploit, an advisory and a note by Microsoft acknowledging the bug, your box is not being DoSsed all the time. . Advisories with almost no technical details are bad: They do not provide enough information to let users decide how serious the condition is in their specific situation, quite often lead to the accidental discovery of new bugs (this is not the first time I've seen it). And more important (for me), they make my everyday task of writing exploits harder :-) . Microsoft is already working on fixing the issue. They are trying to target Noveember for a release. . In the meanwhile, filtering ports 135-139 and 445 from the outside is pretty much your only choice... Unless somebody comes out with a home made patch for SRV.SYS. I haven't checked, but I wouldn't be surprised if this could be triggered on UDP, as most standard MAILSLOT transactions are made over UDP. . We tried targeting a Windows Vista beta 2 build 5381, and it didn't crash. So Vista MAY be safe. . Only a few days ago, after we finally closed a new release of CORE IMPACT (v6.0), I could go back and work on the original MS06-035. I got again in touch with HD Moore and Pedram (Thanks again guys!), and they passed me some clues, but I'm still working on getting something working :-( take care, be safe gera [1] http://www.microsoft.com/technet/security/bulletin/ms06-035.mspx [2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3942 [3] http://xforce.iss.net/xforce/alerts/id/231 [4] http://www.milw0rm.com/exploits/2057 [5] http://blogs.technet.com/msrc/archive/2006/07/28/443837.aspx [6] http://www.tippingpoint.com/security/advisories/TSRT-06-02.html [7] http://pedram.redhive.com/blog/2006-07-11/ [8] http://jsgreen.tamu.edu/Not%20my%20job%20award.jpg [9] http://www.funnysnaps.com/possum2.jpg [10] http://www.corest.com/common/showdoc.php?idx=562&idxseccion=10 [11] http://oss.corest.com/projects/impacket.html [12] http://www.snia.org/tech_activities/CIFS/CIFS-TR-1p00_FINAL.pdf