Windows 10 NTFS $i30 File Corruption

Windows 10 v1803 and later are vulnerable to NTFS file corruption when accessing a specially designed path containing the $i30 string, more specifically known as the Windows NTFS Index Attribute string as described at <https://www.osforensics.com/faqs-and-tutorials/how-to-scan-ntfs-i30-entries-deleted-files.html&gt;.

Attackers can remotely exploit this vulnerability to make Windows think a drive is corrupted even though it is not. Successfully resolving this issue will require users to reboot Windows and run a disk check on the corrupted drive, after which Windows will be convinced that the drive is no longer corrupted.

Recent assessments:

gwillcox-r7 at January 15, 2021 6:01pm UTC reported:

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&gt; 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/&gt;.

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.

TheXDS at February 01, 2021 3:38am UTC reported:

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&gt; 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/&gt;.

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.

Assessed Attacker Value: 1
Assessed Attacker Value: 1Assessed Attacker Value: 5