There appears to be a lot of hype at the moment surrounding this vulnerability given the recent Tweets from @jonaslyk on Twitter at https://twitter.com/jonasLyk/status/1347900440000811010 as well as the follow up article from BleepingComputer at https://www.bleepingcomputer.com/news/security/windows-10-bug-corrupts-your-hard-drive-on-seeing-this-files-icon/.

Whilst this bug is made out to sound like a catastrophic disaster in Windows that could result in data loss should a user browse to a malicious file path containing the string C:/:$i30: followed by a file name such as C:/:$i30:$bitmap, the reality is that, at least in my tests, this is not the case. In fact during my tests I found the following:

1. The disk is not actually corrupted. If you try to access files on the disk, you can still interact with them and do things normally without any issues. Windows just somehow thinks that the disk is corrupted, even though it isn’t.
   
2. Rebooting will case Windows to check the disk and try to repair it. If you skip this disk check, Windows will still think that the disk is corrupted, even though your computer will work fine. You will have to run a disk check by going to File Explorer, right clicking on the affected drive such as C:\, clicking Properties, then the Tools tab, and click Check under the Error Checking section. This will then require the computer to reboot, which should be pretty quick (a few seconds in my case for a clean Windows 10 20H2 VM), after which Windows will have self corrected itself and will no longer assume the disk is corrupt.
   
3. You can trigger this remotely via handlers such as the file:// handler so this could be exploited remotely by embedding a HTML link into a web page that invokes the file:// handler on C:/:$i30:$bitmap. This will cause an immediate warning to display on the user’s computer that the drive is corrupted, which may be enough to convince them to reboot. Alternatively the user could just continue to use the computer and ignore the warning with no side effects.
   

So in conclusion this seems more like a logic/state error bug where Windows is tricked into thinking a drive is corrupted when it is not than any real serious issue, at least from the results that I am seeing in a VM. I don’t know if physical computers would be any different as I haven’t tested it on a physical machine, but I do not believe there would be any reason to believe the results would be different.

This is a grave oversight of the way the NTFS driver handles path access to special directory attributes. Any kind of file access that could be performed by Windows where it might need to read a path trying to access the :\(i30:\)Bitmap attribute on a directory from the user’s context will cause the corruption of the accessed directory. If performed over the root directory, the entire drive will be affected.

Simple stuff like crafting a .url file with the path will cause the system to become corrupted. Please, avoid extracting any untrusted .URL/.LNK files from any files you download from the internet.