Mailslot bug (MS06-035) vs non-Mailslot bug (CVE-2006-3942)
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