A Romanian hardware expert has published proof-of-concept code on GitHub that will crash most Windows computers within seconds, even if the computer is in a locked state.
The code exploits a vulnerability in Microsoft's handling of NTFS filesystem images and was discovered by Marius Tivadar, a security researcher with Bitdefender.
NTFS bug & Windows autoplay feature don't go well together
The expert's PoC contains a malformed NTFS image that users can take and place it on a USB thumb drive. Inserting this USB thumb drive in a Windows computer crashes the system within seconds, resulting in a Blue Screen of Death (BSOD).
"Auto-play is activated by default," Tivadar wrote in a PDF document detailing the bug and its impact.
"Even with auto-play [is] disabled, [the] system will crash when the file is accessed. This can be done for [example,] when Windows Defender scans the USB stick, or any other tool opening it."
Microsoft declined to fix
Tivadar contacted Microsoft about the issue in July 2017, but published the PoC code today after the OS maker declined to classify the issue as a security bug.
Microsoft downgraded the bug's severity because exploiting it requires either physical access or social engineering (tricking the user).
The researcher doesn't agree with Microsoft's decision. He first argues that physical access isn't necessarily required, as an attacker could deploy the PoC from afar using malware.
NTFS bug also crashes locked PCs
Tivadar also explained that the NTFS bug was more dangerous than Microsoft thinks because it also works while the PC is locked, a state when the researcher argues the OS shouldn't be reading data from random USB drives that were inserted into its ports.
"I strongly believe that this behavior should be changed, [and] no USB stick/volume should be mounted when the system is locked," the researcher said. "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."
Tivadar published two videos on his personal Google Photos account showing the NTFS bug crashing a PC in normal and locked down states. Another PoC is also available on his Google Drive account.
For now, Tivadar's PoC will become one of the hottest pieces of code on GitHub, as any prankster will be looking to add it to his arsenal.
UPDATE [May 2, 2018]: Tivadar told Bleeping Computer today that the bug still works today, against the latest Windows 10 version, v1803 - the April 2018 Update.
Comments
Bullwinkle-J-Moose - 5 years ago
NTFS Bug failed to Crash Windows 10 (to Go) and failed to crash Windows XP-SP2
Not using UEFI however if that helps
System is set up as IDE mode on Sandy Bridge with "BIOS"
Bullwinkle-J-Moose - 5 years ago
Sorry, wrong boot drive.......
It actually failed to crash Windows 8.1 Enterprise (to Go)
Will try again on Windows 10 shortly as soon as I find my backup
Bullwinkle-J-Moose - 5 years ago
Final Results:
9AM Saturday
Does NOT crash Windows 10 (Fall Creators Update)
Does NOT crash Windows 8.1 Enterprise (Windows 2 Go)
Does NOT crash Windows 7 (90-day Trial)
Does NOT crash Windows XP-SP2
This POC (Piece of Crap) code does not appear to be a threat to non-UEFI systems running in IDE mode
It does NOT appear to be an O.S. specific issue as the article implies
Windows defender did not crash when scanning the USB stick and it made no difference how I accessed the pseudo malware
Autoplay had no affect
Exnor - 5 years ago
"Final Results:
9AM Saturday
Does NOT crash Windows 10 (Fall Creators Update)
Does NOT crash Windows 8.1 Enterprise (Windows 2 Go)
Does NOT crash Windows 7 (90-day Trial)
Does NOT crash Windows XP-SP2
This POC (Piece of Crap) code does not appear to be a threat to non-UEFI systems running in IDE mode
It does NOT appear to be an O.S. specific issue as the article implies
Windows defender did not crash when scanning the USB stick and it made no difference how I accessed the pseudo malware
Autoplay had no affect"
Can you explain how the UEFI has any impact on the OS behavior when accessing a file?
I don't see a relation here, but i would like to know.
Thanks.
Bullwinkle-J-Moose - 5 years ago
"Can you explain how the UEFI has any impact on the OS behavior when accessing a file? "
-----------------------------------------------------------------------------------------------------------------------------------
No, what I CAN tell you is that I simply tested with BIOS on an INTEL system using internal graphics
If I were to guess, as the "Romanian hardware expert" did, I would think that the one O.S. he used that did not crash was an entirely different computer
I would then "think" that maybe he switched from an AMD system to an INTEL system
Did he switch from external graphics to internal ?
But I'm not going to guess as he did
If you know what changed on his system, please let us know!
All I can tell you is that this is not a threat on "MY" system
To claim that it is a problem for "most" Windows systems seems a bit disingenuous
HOW DO YOU KNOW?
To claim that it affect ALL RECENT VERSIONS of Windows is clearly false
(These were claims made by the author of this article - Catalin Cimpanu)
To clarify my results
Windows 10 was actually a full install of Windows 10 "PRO" - Fall Creators update (not Win2Go)
It was an INTEL CPU using INTERNAL graphics
What was different on his system when he got different results?
Exnor - 5 years ago
""Can you explain how the UEFI has any impact on the OS behavior when accessing a file? "
-----------------------------------------------------------------------------------------------------------------------------------
No, what I CAN tell you is that I simply tested with BIOS on an INTEL system using internal graphics
If I were to guess, as the "Romanian hardware expert" did, I would think that the one O.S. he used that did not crash was an entirely different computer
I would then "think" that maybe he switched from an AMD system to an INTEL system
Did he switch from external graphics to internal ?
But I'm not going to guess as he did
If you know what changed on his system, please let us know!
All I can tell you is that this is not a threat on "MY" system
To claim that it is a problem for "most" Windows systems seems a bit disingenuous
HOW DO YOU KNOW?
To claim that it affect ALL RECENT VERSIONS of Windows is clearly false
(These were claims made by the author of this article - Catalin Cimpanu)
To clarify my results
Windows 10 was actually a full install of Windows 10 "PRO" - Fall Creators update (not Win2Go)
It was an INTEL CPU using INTERNAL graphics
What was different on his system when he got different results?
"
I still don't understand...
Ok so you used a different machine, but how do you relate that with UEFI vs non UEFI ? Is there a vulnerability using UEFI and Windows when accessing the file system? I don't get it. Sorry.
mx386 - 5 years ago
I wonder whether you got right this phrase "...PoC contains a malformed NTFS image that users can place on a USB thumb drive..."
Did you just copied tinyntfs to your USB drive as an regular file?
Or did you reimagined content of your USB drive with this image?
Windows will certainly ignore any such file on your drive and be happy about it's malformed file system.
Bullwinkle-J-Moose - 5 years ago
The discrepancy between Cimanu's and Tivadar's description is problematic when calling this a Windows File Handling Bug
To simply copy the malformed image to a thumb drive as Cimpanu describes, and then instantly crash all recent versions of Windows "could" be considered a Windows file handling problem "IF" that were actually happening, but it's not!
------------------------------------------------------------------------------
In Tivadar's description, the attack consists of modifying root directory name, also it’s INDEX_ALLOCATION in three places.
Tivadars method is not a Windows file handling problem even if it does crash Windows!
It would be like saying Intel CPU's have a boot problem when I hit them with a hammer
Catalin Cimpanu:
The expert's PoC contains a malformed NTFS image that users can take and place it on a USB thumb drive. Inserting this USB thumb drive in a Windows computer crashes the system within seconds, resulting in a Blue Screen of Death (BSOD).
"Auto-play is activated by default," Tivadar wrote in a PDF document detailing the bug and its impact.
"Even with auto-play [is] disabled, [the] system will crash when the file is accessed. This can be done for [example,] when Windows Defender scans the USB stick, or any other tool opening it."
-----------------------------------------------------------
Marius TIVADAR: (PDF)
Preparing the image
As a proof of concept, I attached a 10MB NTFS image.
The attack consists of modifying root directory name, also it’s INDEX_ALLOCATION in three places.
1. In the PoC image, I took file record 5 (root), modified it’s name: ’.’ to ’4’, offset 0x3564da in file.
2. Then, in INDEX_ALLOCATION of root, we take an arbitrary entry and overwrite it’s file name
with the same name as modified root, in our case ’4’, offset 0x02c542 in file.
3. Also, in the same INDEX_ALLOCATION entries, we take the entry that contains the root directory
’.’ , we modify it’s name with ’4’, offset 0x02c4ea in file.
Bullwinkle-J-Moose - 5 years ago
UEFI vs non UEFI ?
It should be irrelevant
I don't even know why I mentioned it other than it is different from what most people use today and I was tired
Lets move on to why it breaks his machine!
This does not appear to be a file handling problem for Windows
Is it an AMD vs INTEL problem?
Driver Problem?
What was different to make it crash his machine?
Have you tried it and does it crash YOUR machine?
If it crashes YOUR machine, please list the hardware with any ideas as to why
I do not see it as a file handling problem for "Recent Versions of Windows", or ANY versions of Windows and I can understand why Microsoft did not consider it a Windows Problem
Do you see it differently?
Exnor - 5 years ago
"UEFI vs non UEFI ?
It should be irrelevant
I don't even know why I mentioned it other than it is different from what most people use today and I was tired
Lets move on to why it breaks his machine!
This does not appear to be a file handling problem for Windows
Is it an AMD vs INTEL problem?
Driver Problem?
What was different to make it crash his machine?
Have you tried it and does it crash YOUR machine?
If it crashes YOUR machine, please list the hardware with any ideas as to why
I do not see it as a file handling problem for "Recent Versions of Windows", or ANY versions of Windows and I can understand why Microsoft did not consider it a Windows Problem
Do you see it differently?"
I was only concern in knowing if there was a relation between a UEFI system and this reported "bug/vulnerability".
No i did not test it and have no intentions on doing it, at least not on a non VM environment... And i sure do not have the knowledge to debug the problem so it would be just to see if the problem presents itself...
I was worried if there was any relation on how a UEFI system and the OS (windows in this case) interact because if that was the case the problem (assuming there is one) could had other ramifications, that is why i asked you to give me some information... because i do not know.
the_moss_666 - 5 years ago
I'am not sure either, but UEFI boot is sometimes requirment for installing OEM Windows. Installing Windows in UEFI mode also creates "EFI" partition on HDD, so this might be the UEFI-file system connection.
linuxmaster - 5 years ago
Another reason why I use Linux, and Winblows in virtual in Linux!
snifferdog - 5 years ago
@linuxmaster Good for you. What a pointless comment.
I do however agree with the original researcher that autoplay should not kick in while the PC is locked, and, if this really is a bug, then MS should certainly fix it. Having your machine crash (or worse, become compromised, maybe) just by plugging in a USB stick is clearly not acceptable. I recall there was once a virus in one of those smart photoframes. Well, here's another opportunity for whoever wrote that.
thx1200 - 5 years ago
Easily crashing a computer is an interesting bug, but Microsoft was correct, it's not a security issue and should not be classified as such. If a system gets to the bugcheck screen, the OS has already halted, there's nothing for a hacker to take advantage of.
Unless it allowed an escalation of privilege or access to protected data, it's just a regular bug. And seeing as how Microsoft has already fixed it on latest Win10 builds, it's a non-issue.
butkracker - 5 years ago
This just crashed my Vmware windows on mac.