Microsoft will not rush out an emergency patch for a zero-day vulnerability disclosed on Wednesday in the Windows implementation of the Server Message Block protocol.
Researcher Laurent Gaffie announced in a tweet, below, that he’d found a zero-day vulnerability in SMBv3 and released a proof-of-concept exploit. He told Threatpost that he privately disclosed the issue to Microsoft on Sept. 25 and that Microsoft told him it had a patch ready for its December patch release, but decided to wait until its scheduled February update to release several SMB patches rather than a single fix in December. Microsoft considers the vulnerability, a remotely triggered denial-of-service bug, low-risk.
SMBv3 0day, Windows 2012, 2016 affected, have fun 🙂 Oh&if you understand this poc, bitching SDLC is appropriate 🙂https://t.co/xAsDOY54yl
— Responder (@PythonResponder) February 1, 2017
“Windows is the only platform with a customer commitment to investigate reported security issues, and proactively update impacted devices as soon as possible. Our standard policy is that on issues of low risk, we remediate that risk via our current Update Tuesday schedule,” a Microsoft spokesperson told Threatpost in email statement. The next scheduled Microsoft update is Feb. 14.
Gaffie said the vulnerability is specifically a null pointer dereference in SMB and that it affects Windows Server 2012 and 2016. He added that a joint analysis between himself and Microsoft concluded that code execution doesn’t seem possible through an exploit of this vulnerability. SMB is generally not exposed to the Internet, though Gaffie said that outbound connections where clients connect to remote file servers are more likely to be allowed than inbound SMB connections over an open port 445.
“This bug can be used to trigger a reboot on a given target, it can be either local (via netbios, llmnr poisoning) or remote via a UNC link (example: adding an image with a link: \\attacker.com\file.jpg in an email),” Gaffie said. “It’s important to note that this trivial bug should have been caught immediately by their SDLC process, but surprisingly it was not. “This means that the new code base was simply not audited or fuzzed before shipping it on their latest operating systems.”
Gaffie also said he decided to release details prior to the availability of a patch because it’s not his first experience working with Microsoft where they have delayed a patch release for one of his bugs.
“I decided to release this bug one week before the patch is released, because it is not the first time Microsoft sits on my bugs,” he said. “I’m doing free work here with them (I’m not paid in anyways for that) with the goal of helping their users. When they sit on a bug like this one, they’re not helping their users but doing marketing damage control, and opportunistic patch release. This attitude is wrong for their users, and for the security community at large.”
Johannes Ullrich, dean of research at the SANS Institute and director of the SANS Internet Storm Center, said he ran Gaffie’s exploit and could confirm that it caused a crash on a fully patched Windows 10 system.
“Modern Windows versions have several protection mechanisms to prevent remote execution for exploits like this,” Ullrich said. “It would likely be difficult, but not necessarily impossible.”
Ullrich published a post on the SANS ISC site describing his testing of Gaffie’s exploit. The PoC would require an attacker to send a link to a victim, luring them to connect to a malicious SMB server instance.
“A URL like \\[server ip address\IPC$ would trigger the exploit,” Ullrich said. “I have tested it in Edge and Internet Explorer on Windows 10 with a local html file like that and it shut down the system immediately.
“The exploit implements its own SMB server, so it is as easy as running the exploit, making sure the user can connect (e.g. firewall issues) and then sending the ‘right’ link to the user,” Ullrich said. “This is pretty easy to exploit. Took me maybe 10 minutes to get it to work. The exploit comes without instructions.”
Ullrich explained that the attacker will respond with a crafted Tree Connect Response—Tree Connect Requests are sent to Windows Servers when users connect to shares—that is lengthy and also includes a “long trailer.” He explained in the SANS ISC post that the tree connect response message consists of a NetBIOS header and message type of a total length of 1580 bytes, and a SMB2 header that is 64 bytes long. The Tree Connect Response message has a fixed length of 8 bytes in addition to the fixed header.
“This is where the message should end. But apparently, since the total message size according to the NetBIOS header is larger, Windows keeps on decoding in the crafted header (all ‘C’s’ in the exploit), which then triggers the buffer overflow,” Ullrich said.
