A proof of concept for easily generating the blue screen of death (BSOD) on Windows devices has been released, along with a video demonstrating that the denial-of-service effect can take place even if the device is locked.
Using a handcrafted image of a Windows NT file system (NTFS) loaded onto a USB stick, it’s possible to crash the system by simply inserting the drive into the USB port, no further user interaction necessary (as this pair of videos shows).
“Auto-play is activated by default, this leads to automatically crashing the system when [the] USB stick is inserted,” said Bitdefender researcher Marius Tivadar, in a post on GitHub from late last week exposing the problem and the PoC. “Even with auto-play disabled, system will crash when the file is accessed. This can be done…when Windows Defender scans the USB stick [even when locked], or any other tool opening it. If none the above, finally, if the user clicks on the file, system will crash.”
Further, he added that while his own PoC requires physical access to the device with a USB stick, it’s possible to code the attack into malware that could be delivered remotely via spam campaigns or even drive-by downloads.
“If this kind of crash was exploitable, and attacker could load malware even if the system is locked, [and] this could open thousands of possible scenarios,” he said in the supporting materials for the PoC. “Of course, it is not necessary to have an USB stick. A malware for example could drop a tiny NTFS image and mount it somehow, thus triggering the crash.”
Also, he told Threatpost that inserting a memory stick when a computer is in a locked state triggers the execution of plenty of OS code, such as mounting file systems. “This could be dangerous if the file system is handcrafted and aimed at exploiting the OS. This behavior should be changed for any operating system,” Tivadar said.
All three systems he tested were affected: Windows 7 Enterprise 6.1.7601 SP1, Build 7601 x64; Windows 10 Pro 10.0.15063, Build 15063 x64; and Windows 10 Enterprise Evaluation Insider Preview 10.0.16215, Build 16215 x64.
For Microsoft’s part, he said that its security team was initially responsive, but was uninterested in issuing a patch when he reached out to the software giant with the problem.
“Reported to Microsoft on July 2017, they did not want to assign CVE for it nor even to write me when they fixed it,” said Tivadar, who discovered the issue last summer. In his GitHub posting, he reprinted an email that he said was from the Microsoft team, which read, “Hey Marius, your report requires either physical access or social engineering, and as such, does not meet the bar for servicing down-level (issuing a security patch)…Your attempt to responsibly disclose a potential security issue is appreciated and we hope you continue to do so.”
Microsoft offered a short statement in response to our request for comment: “The technique described requires authenticated access to a machine. We encourage customers to always use security best practices, including securing work stations and avoiding leaving laptops and computers unattended.”
Tivadar said that he believes the problem is genuinely worthy of concern. “As a security researcher, I think that every vulnerability that requires physical access and/or social engineering is important,” he told Threatpost. “I’ve seen and studied malware like FLAME and Stuxnet, that may have been spread using physical access (FLAME and Stuxnet contained a zero-day exploit that forced the OS to run malware from a removable drive). [And] we all know the stories Kevin Mitnick taught us regarding social engineering, so yes, these types of bugs are important.”
In his post, he added: “I strongly believe that this behavior should be changed…Generally speaking, no driver should be loaded, no code should get executed when the system is locked and external peripherals are inserted into the machine. I may think [of] this as code [that] gets executed without user consent.”
