New flaw can crash Windows Vista and Server 2008 remotely (Updated)

Microsoft is investigating reports of a new vulnerability that affects both …

Redmond is investigating reports that a newly discovered flaw in Microsoft's implementation of the Server Message Block 2 (SMB2) protocol, an extension of the conventional server message block protocol, can be exploited to remotely crash and restart computers running Windows Vista or Windows 7. The attack does not require authentication, but port 445 of the target system must be open, and on Windows it is open by default. Laurent Gaffi�, who discovered the vulnerability, has contacted Microsoft, noting that the only solution he can think of is to turn off the SMB feature and close port 445.

Gaffi� says the vulnerability is a result of how the srv2.sys driver handles client requests when the header of the "Process Id High" field contains an ampersand (this isn't the first time an ampersand has caused trouble for Microsoft): "SRV2.SYS fails to handle malformed SMB headers for the NEGOTIATE PROTOCOL REQUEST functionality. 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 further communication."

Windows Server 2008 may also be vulnerable, as it uses the same SMB2 driver, but Gaffi� has not tested the flaw against the server operating system. The flaw could also potentially lead to a denial of service attack or remote code execution.

Update

Microsoft has now issued Security Advisory 975497 in regards to the issue. The software giant noted its concern that this new report of a vulnerability was not responsibly disclosed, potentially putting computer users at risk, but that it is not aware of any attacks that try to use the reported vulnerabilities. Redmond says it may provide a security update on Patch Tuesday or an out-of-cycle patch once it is ready.

Microsoft listed two workarounds for the flaw: disable SMB v2 and block TCP ports 139 and 445 at the firewall. The company also gave three mitigating factors,

Firewall best practices and standard default firewall configurations can help protect networks from attacks that originate outside the enterprise perimeter. Best practices recommend that systems that are connected to the Internet have a minimal number of ports exposed. In this case, the SMB ports should be blocked from the Internet.

In Windows Vista, if the network profile is set to "Public", the system is not affected by this vulnerability, since unsolicited inbound network packets are blocked by default.

Windows 7 and Windows Server 2008 R2 are not affected by this vulnerability.

That's right, despite the initial reports, Microsoft says that only Windows Vista and Windows Server 2008 are affected. This is good news for everyone who has already gotten their hands on the latest versions of Windows and Windows Server, though it should be noted that the Windows 7 RC is indeed affected.

Actually, I think all ISPs block SMB for home users by default anyhow. They learned that after the blaster worm incident (different port, but still).

In Vista, if you have your network profile set to home, and you turned on file and printer sharing, it will be open. I think in XP it was always added as an exception, and while Vista makes it easy to switch to public mode when a new network is used, XP I believe expects you to turn off exceptions.

I would just like to know how this kind of error goes by undetected by quality assurance/whatever department is in charge of this. I mean, I do understand that these products are made with a given budget and all, but how exactly do you plan on getting some input and let an & ruin your day like that? I code. My code is by no means perfect, and since I don't know how exactly this is coded I can't tell whether this was a childish mistake or not, but I am of the criteria that if the user can make any sort of input to the system (telnet to remote machine on port 445), the user will try to break something. Yeah, there's the dancing bunny paradigm here, still, man, messing up a pointer I understand (cast variable/function return as pointer to void to cast address of variable/function return as pointer to void is pretty lame though), but this is just wrong...

Originally posted by LinuxMonkey007:I would just like to know how this kind of error goes by undetected by quality assurance/whatever department is in charge of this. I mean, I do understand that these products are made with a given budget and all, but how exactly do you plan on getting some input and let an & ruin your day like that? I code. My code is by no means perfect, and since I don't know how exactly this is coded I can't tell whether this was a childish mistake or not, but I am of the criteria that if the user can make any sort of input to the system (telnet to remote machine on port 445), the user will try to break something. Yeah, there's the dancing bunny paradigm here, still, man, messing up a pointer I understand (cast variable/function return as pointer to void to cast address of variable/function return as pointer to void is pretty lame though), but this is just wrong...

Vulnerabilities to carefully crafted inputs is very difficult to test for except when testing for certain known patterns. It's easier to audit the code and make sure it isn't doing anything idiotic, especially if a static analysis tool can do the bulk of the work, or to hire competent programmers so they don't write code vulnerable to buffer overflows, etc.

I haven't tested Windows 7 RTM (and I see MS is claiming it's not vulnerable) but the RC is very much susceptible to this attack (assuming you have SMB turned on). I've crashed my Win7 x64 RC VM successfully several times today.

Originally posted by LinuxMonkey007:I would just like to know how this kind of error goes by undetected by quality assurance/whatever department is in charge of this. I mean, I do understand that these products are made with a given budget and all, but how exactly do you plan on getting some input and let an & ruin your day like that? I code. My code is by no means perfect, and since I don't know how exactly this is coded I can't tell whether this was a childish mistake or not, but I am of the criteria that if the user can make any sort of input to the system (telnet to remote machine on port 445), the user will try to break something. Yeah, there's the dancing bunny paradigm here, still, man, messing up a pointer I understand (cast variable/function return as pointer to void to cast address of variable/function return as pointer to void is pretty lame though), but this is just wrong...

All Microsoft has to do is test every know way that input can be passed, in every known configuration. I don't see what's so hard about that.

Originally posted by LinuxMonkey007:I would just like to know how this kind of error goes by undetected by quality assurance/whatever department is in charge of this. I mean, I do understand that these products are made with a given budget and all, but how exactly do you plan on getting some input and let an & ruin your day like that? I code. My code is by no means perfect, and since I don't know how exactly this is coded I can't tell whether this was a childish mistake or not, but I am of the criteria that if the user can make any sort of input to the system (telnet to remote machine on port 445), the user will try to break something. Yeah, there's the dancing bunny paradigm here, still, man, messing up a pointer I understand (cast variable/function return as pointer to void to cast address of variable/function return as pointer to void is pretty lame though), but this is just wrong...

All Microsoft has to do is test every know way that input can be passed, in every known configuration. I don't see what's so hard about that.

Originally posted by Rura Penthe:I haven't tested Windows 7 RTM (and I see MS is claiming it's not vulnerable) but the RC is very much susceptible to this attack (assuming you have SMB turned on). I've crashed my Win7 x64 RC VM successfully several times today.

We were crashing the TechNet/MSDN "RTM" build today at work just fine.

EDIT: Actually, come to think of it, it may have been the RC that we were crashing.

Vista's "helpfulness" may make this problem a little worse by encouraging people to turn on file sharing. When browsing the network in Vista, if you haven't enabled file sharing, a yellow bar at the top of the window will display

quote:

File sharing is turned off. Some network computers and devices might not be visible. Click to change...

I'm not sure exactly what they're talking about because I just turned it back off and I still see UPnP Media Devices, my router, an old NAS (Buffalo Terastation), and my own computer. Maybe they'll disappear after a reboot.

Anyone implementing a network protocol: please use (at the very least) FUZZ TESTING during implementation. There is no excuse for handling input so badly that you actually crash the entire system above you.