Mikael wrote us yesterday, telling us about a site claiming to have a zero day for SMB on both Windows 7 and Windows Server 2008 R2.  Thanks for the pointer Mikael,  Laurent Gaffié is the original author of this bit of code.

However, after a first try, we found that the code didn't run as posted.  Nothing major, one required line of code was missing, and some formatting issues.  Given what this code does, these omissions might have been intentional, to give Microsoft a chance to get a fix in before this disseminates.  The code does in fact work.  The sequence to see the exploit is:

1/ On a linux machine, ensure that port 445 is open or that your firewall is down - ensure that the target windows host and the linux host have connectivity (a quick ping does the trick here)

2/ On that linux box, run the resulting code - "sudo python w7spolit.py" .  Note that you need sudo to open a tcp service, and we're using a linux box for this because of course port 445 is taken on most windows hosts.

3/ On the target Windows box, do a "net use x.x.x.x", where x.x.x.x is the ip address of the linux box.

You'll see that the Windows host is now frozen - no mouse, no keyboard, and completely unresponsive on the network as well.  This works on both Windows 7 and Windows Server 2008 R2, with the very latest patches applied.  A link to a server running this code could easily be embedded in a web page or email, pointing out to a "poison" host on the internet -  so this exploit is not isolated to corporate networks doing file sharing.  As the author states, disabling SMBv2 does not give even temporary protection.  Here's hoping Microsoft scrambles the troops to get this patched before it's out in the wild.

 ==========================================================================================================================

 Since the original post, there's been a lot of Q&A back and forth, and also some mis-information floating around as well, I'm hoping that the Q&A below helps clarify things:

Is the original Windows 2008 affected by this?
No - the only 2 affected operating systems are Windows 7 and Windows 2008 R2

What patch levels have been tested? Is this a problem in one patch or another?
We've only tested the 2 affected operating systems, fully patched as of 12 Nov 2009.

If I disable SMBv2, I'm not affected right?
Wrong.  This affects hosts whatever version of SMB they are running. We've tested hosts with SMBv2 disabled with both the registry method and the "sc" method (singly and in combination), and all are equally affected.

How does this thing spread?
It has no mechanism for propagation.  Unless somebody embeds this in a worm, this is more of a curiosity than anything else.  This vulnerability in itself does not have the potential to steal information or compromise system integrity.  It crashes hosts, plain and simple.

Is IPv6 affected?  Is this an IPv6 problem?
This is an SMB issue (tcp/445).  All testing so far has been on IPv4, we haven't tested IPv6 specifically, but there's no reason to think that running SMB over IPv6 would behave any differently

What about the firewall on windows?  Does that help?
Remember that this works by you browsing to a UNC on a "poison" host.  The windows firewall has no affect on this
 
How can I mitigate against this in Windows? Is there a registry key or a patch I can apply?
At this time, there is no host based mitigation available.  We're hoping that Microsoft comes out with a patch for this quickly.  Your best protection is the same "safe computing" advice that we'd give any other day:

• Don't browse from your servers.   Ever.
• Don't browse indiscriminately from your workstation (don't click links from strangers).  
• Don't browse to UNC's that aren't under your control (i.e. on the public internet).  Ever.

Can I protect myself in any way?
YES.  Your best protection in a corporation is an egress filter on your firewall.  This has been a long-standing recommendation, and not just from SANS.  There is no reason you should browse to Microsoft file sharing ports on the internet, so blocking this activity outbound on a corporate firewall is a great way to knock this problem on the head, at least as far as your corporation is concerned.  Egress filters are also a wonderful way to stop the propagation (both inbound and outbound) of other malware.  There are a number of papers in the SANS Reading Room ( http://www.sans.org/reading_room/ ) that deal with this subject if you want more info.

Why haven't you post a link to the original code?
As a policy, ISC simply can't post links to zero day code.  We need to report this as an important story, getting the word out to prevent the spread of FUD is key in situations like this.  However, pointing to the author's blog just wouldn't be responsible.  If you'd like to try this code out yourself, most search engines should be able to help you with that.


Finally, remember again that this is not like the vulnerabilities that have recently seen widespread adoption by malware.  This vulnerability does not "infect" Windows, it simply crashes the host.  Crashing hosts is not "good business" for criminals - remember, they write their malware to make money, and crashing your victim's host does not make any money most days.  Also, it requires action by someone on the target host - they need to browse to a UNC resource on the attacker's "poison" host.   While this vulnerability is a serious issue, I can't see a good reason for malware authors to include it in their suite.  I don't expect that we'll see widespread use of this "in the wild" (except on security blogs of course ...)