II. BACKGROUND-------------------------Windows vista and newer Windows comes with a new SMB version named SMB2.See: http://en.wikipedia.org/wiki/Windows_Vista_networking_technologies#Server_Message_Block_2.0for more details.

III. DESCRIPTION-------------------------[Edit]Unfortunatly this SMB2 security issue is specificaly due to a MS patch, for another SMB2.0 security issue:KB942624 (MS07-063)Installing only this specific update on Vista SP0 create the following issue:

SRV2.SYS fails to handle malformed SMB headers for the NEGOTIATE PROTOCOL REQUEST functionnality.The NEGOTIATE PROTOCOL REQUEST is the first SMB query a client send to a SMB server, and it's used to identify the SMB dialect that will be used for futher communication.

IV. PROOF OF CONCEPT-------------------------

Smb-Bsod.py:

#!/usr/bin/python#When SMB2.0 recieve a "&" char in the "Process Id High" SMB header field #it dies with a PAGE_FAULT_IN_NONPAGED_AREA error

VII. SOLUTION-------------------------No patch available for the moment.Close SMB feature and ports, until a patch is provided.Configure your firewall properlyYou can also follow the MS Workaround:http://www.microsoft.com/technet/security/advisory/975497.mspx

XI. LEGAL NOTICES-------------------------The information contained within this advisory is supplied "as-is"with no warranties or guarantees of fitness of use or otherwise.I accept no responsibility for any damage caused by the use ormisuse of this information.

XII.Personal Notes-------------------------Many persons have suggested to update this advisory for RCE and not BSOD:It wont be done, if they find a way to execute code, they will publish them advisory.

"Anonymous said... If this vuln is real. Why didnt you reported it to Microsoft MSRC? Because it looks really stupid to publish this kind of thing on Full disclosure."

He may have months ago. Security through obscurity. If there's an inherent problem, it's important for anyone to allow end-users to make an informed decision about the risks involved. In short; MS need to jump on this with both feet rather than dawdle as is there usual response.

What release of Windows 7 did u use?. Im running the script on a Debian against a Windows 7 ultimate 64bits and a 32bits (both are 7600) and didn't work. I have file sharing enabled, i can access both computer resources from a Windows XP without any problem (and im not even asked for user/password as i have it configured to not get asked for user/pass if that matters).

He received a reply saying that no patch was available along with a workaround and he decided to post the exploit live anyway instead of waiting until it was fixed? Could a person be any more of a jerk? Microsoft takes all SMB vulnerabilities seriously, but instead of doing everyone a favor and just waiting until a patch were to be released, you decided to open it up to a realm of script kiddies bored at school/work who'll try to inflict as much damage as possible.

After giving MS ample time to rectify the problem it is imperative that the information and work around be disclosed far and wide. MS was notified, failed to promptly release a patch, so the matter is now in the hands of the public domain to manage.

If you properly firewalled your ports properly in the first place the exploit would be a non-issue.

Releasing this allows people to protect themselves before there's a patch. You're assuming that only HE has found the exploit, a white-hat with good intentions. You think other people who might have found this are going to be so nice?

I'm having trouble getting it too work, but that just could be because it's complaining about bad headers in the crafted packet (it's been a while since i've done this..). Testing it out against win7 32 and 64 at home..hope to have results soon. Wireshark capture shows the packet is received by the remote computer and responded too, but no bsod. The problem seems to be in the header checksum.

I imagine a group of blackhats getting angry cause yet another hidden 0day was disclosed :-P So I don't think people should get angry at Laurent, I'd do the same, willingly knowing that some script kiddies, worm makers and such would abuse it as well. But that's just the yin and yang principle.

HDM has by the way also added another module to the Metasploit framework which exploits another bug in the negotiate protocol / smb service.

With all respect to Laurent and other commenters, the importance of not disclosing this kind of things is that: even with a disclosure a lot of good people won't know of it.Instead, a lot of non-capable attackers now might have a method to harm, that would never have discovered on their own. Microsoft will develop a solution, release a patch and still a lot of customers will be vulnerable months later. (cont.)

(cont.) Making Microsoft face red does not help anyone. While you have the right to tire of post-exploit patching, experience demonstrates that patching accelerates exploiting, and makes it broader.Those who have a good IT management practice will probably not be vulnerable with or without a patch. Those who are vulnerable now are only exposed to a greater risk.

One news outlet reported that Laurent submitted the bug to Microsoft, but there was a typo in the e-mail address.

Mistakes happen, but a little extra effort to contact the vendor could have been made. I know that Microsoft has forms, forums, and telephone numbers. Not saying you got to contact them all, but a single e-mail does not due diligence make.

If there was no response after several attempts over several days, then a public disclosure is warranted.

You didn't submitted the bug to the editor (or with a typo in the address, are you not able to type an address or was it on purpose), you post a proof of concept on patch day, when MS has no time to fix the hole before next month. It looks like you did everything on purpose.It would be funny for MS if nobody would use their software for important things. Today I saw a girl in my college who was weeping: she lost all her work because of script kiddies who reboot all the computers. Her exam is tomorrow.

Anyone (including MS) who would have tested this critical component would have found this bug in a matter of seconds.

It showed this specific bug (my payload) was introduced by a security patch (MS07-063), showing us no S.Q.A and security testing as been done on it before shipping it on any P.CEven worse; an official Microsoft spokeman told Robert Lemos :"We found this issue independently through our fuzzing processes and implemented the fix into Windows 7 RTM (release to manufacturer)and Windows Server 2008 R2," see: http://www.technologyreview.com/blog/unsafebits/24105/?a=f

This mean, they knew about this issue but failed at protecting them customers.Now that i published the remote teardrop advisory, they use the word "irresponsible disclosure" while patching on emergency what theyknew since a long time.This is a serious error, as the bug was very easy to find, it was only a matter of time before someone disclose it...

Hello guys, I have a file server(windows server 2008), but when I disable the smb2 it disconnect all the map drive of my client (in local network) do you know how to disable smb2 without interrupting map dire (file sharing)Thanks in advance.

"It would be funny for MS if nobody would use their software for important things. Today I saw a girl in my college who was weeping: she lost all her work because of script kiddies who reboot all the computers. Her exam is tomorrow."

Tried running the script on my windows 7 virtual machine. packets were being sent and received (as noticed on wireshark) however, windows 7 did not crash. has the patch been made on the recent releases of windows 7? i had downloaded my present copy from msdnaa a week back...

Security through obscurity. If there's an inherent problem, it's important for anyone to allow end-users to make an informed decision about the risks involved. In short; MS need to jump on this with both feet rather than dawdle as is there usual response.