Message-ID: <a116aff00608151554k5256099wff06f17bdd0eccd1@mail.gmail.com>
Date: Wed, 16 Aug 2006 03:54:40 +0500
From: naveed <naveedafzal@...il.com>
To: "Gerardo Richarte" <lists@...e-sdi.com>
Cc: bugtraq@...urityfocus.com
Subject: Re: Mailslot bug (MS06-035) vs non-Mailslot bug (CVE-2006-3942)

""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.""
i think it could be and a possiblity to be triggered as broadcast
by the way nice analysis , it clarified a few more things :)

On 8/15/06, Gerardo Richarte <lists@...e-sdi.com> wrote:
>
>               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
>
>
>

Powered by blists - more mailing lists