Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Data Storage Bug Windows

Windows 10 Bug Corrupts Your Hard Drive On Seeing This File's Icon (bleepingcomputer.com) 96

Posted by BeauHD from the currently-unpatched dept.
An unpatched zero-day in Microsoft Windows 10 allows attackers to corrupt an NTFS-formatted hard drive with a one-line command. Bleeping Computer reports: In August 2020, October 2020, and finally this week, infosec researcher Jonas L drew attention to an NTFS vulnerability impacting Windows 10 that has not been fixed. When exploited, this vulnerability can be triggered by a single-line command to instantly corrupt an NTFS-formatted hard drive, with Windows prompting the user to restart their computer to repair the corrupted disk records. The researcher told BleepingComputer that the flaw became exploitable starting around Windows 10 build 1803, the Windows 10 April 2018 Update, and continues to work in the latest version. What's worse is, the vulnerability can be triggered by standard and low privileged user accounts on Windows 10 systems. [...] It is unclear why accessing this attribute corrupts the drive, and Jonas told BleepingComputer that a Registry key that would help diagnose the issue doesn't work.

One striking finding shared by Jonas with us was that a crafted Windows shortcut file (.url) that had its icon location set to C:\:$i30:$bitmap would trigger the vulnerability even if the user never opened the file! As observed by BleepingComputer, as soon as this shortcut file is downloaded on a Windows 10 PC, and the user views the folder it is present in, Windows Explorer will attempt to display the file's icon. To do this, Windows Explorer would attempt to access the crafted icon path inside the file in the background, thereby corrupting the NTFS hard drive in the process. Next, "restart to repair hard drive" notifications start popping up on the Windows PC -- all this without the user even having opened or double-clicked on the shortcut file.
This discussion has been archived. No new comments can be posted.

Windows 10 Bug Corrupts Your Hard Drive On Seeing This File's Icon More

Windows 10 Bug Corrupts Your Hard Drive On Seeing This File's Icon

Comments Filter:

  • BSOD would ever be an issue in 2021.
    Wait it fucks up storage devices, well at least we have advanced.

    • Bobby MF Tables
      cd Robert/$i30/$clusterfuck

    • Re: (Score:3, Interesting)

      by arglebargle_xiv ( 2212710 )
      This is a nearly forty-year-old class of bug going back to MSDOS 2.0, where using filenames that were actually (pseudo-)device names could crash your real-mode single-tasking boot loader. Good to see Microsoft is still carefully maintaining backwards-compatibility with these ancient bugs on a multi-core multi-tasking protected-mode virtualised OS.

      • Re:Who would a thunk.. (Score:5, Informative)

        by tlhIngan ( 30335 ) <slashdot.worf@net> on Friday January 15, 2021 @05:06AM (#60947054)

        This is a nearly forty-year-old class of bug going back to MSDOS 2.0, where using filenames that were actually (pseudo-)device names could crash your real-mode single-tasking boot loader. Good to see Microsoft is still carefully maintaining backwards-compatibility with these ancient bugs on a multi-core multi-tasking protected-mode virtualised OS.

        Close, but not quite. This has nothing to do with special files. Windows NT is closer to Unix in the "everything is a file" concept and you can get really weird file nodes like \\.\PhysicalDrive\Disk0\ to represent the disk (basically /devsdX on Linux). But you can do things like \\.\PhysicalDrive\Disk0\C:\blah to access the file as well (the drives are mapped internally by the Windows kernel so you just see C:\ and such).

        Here, NTFS special files are regular files as well. So the free bitmap, which is usually hidden away in the superblock, is $bitmap and is a regular file. In fact, the MFT (Master File Table) which is the list of inodes on the disk is $MFT and can be treated as a regular file. There are special special files representing bad block tables and such on NTFS as well.

        The NTFS superblock basically contains two pointers in it - the pointer to the MFT, and the pointer to the backup critical MFT, which contain the first 16 rows of the master MFT. The first entry in the MFT is the MFT itself (it's a regular file so you kind of need to know where the rest of the MFT is on the disk in case it gets fragmented) and the rest are the rest of the special files.

        Many disk defragmentation programs will defragment the MFT as well, and sometimes for seek efficiency, the MFT is placed in a more central part of the disk - like I said, it's a regular file and the standard Windows file movement APIs (used to defragment the disk) will do the right thing.

        The thing is, when you use $bitmap as the icon source it can corruptsthe disk bitmap. But the disk bitmap is simply an optimization that helps you quickly find free space on the disk when allocating files. It's possible to rebuild it as the MFT will contain a list of every file on disk as well as their location and extents, so you can rebuild $bitmap from the MFT easily.

        • But surely reading an icon is a read only operation, why is the $bitmap file getting "corrupted" which means it is getting written too at all ?

          • My guess is that it's a file trigger. :"You're not supposed to be here, so if you are here then something has gone terribly wrong". But then there is nothing stopping you from going there other than the file not being readily listed.

            • Thats the worst possible outcome, self destruction. Imagine any other item doing the same, car has run out of fuel - time to blow self up, etc.

        • Re: (Score:2)

          by Curate ( 783077 )
          You're mixing something up. The post isn't talking about the $BitMap file, which is the volume bitmap. It's talking about the :$I30:$BITMAP attribute, which is present in any non-resident directory including the root directory.

    • Wait it fucks up storage devices, well at least we have advanced.

      "...with Windows prompting the user to restart their computer to repair the corrupted disk records."

      Weird that they don't tell us the results of that repair. Is it just business as usual afterwards or is the whole disk gone?

  • didn't mac system 6 have an bug like this? where if you named an file in the right way it messed up the HDD?

    • Re: (Score:2, Redundant)

      by david.emery ( 127135 )

      System 6 was ~30 years ago.... https://en.wikipedia.org/wiki/... [wikipedia.org]

    • Re: (Score:2)

      by tlhIngan ( 30335 )

      didn't mac system 6 have an bug like this? where if you named an file in the right way it messed up the HDD?

      Even earlier I think - maybe going all the way back to the original Mac System 1.

      Basically to support disk drivers transparently, you can name the driver .something (dot-something, like dotfiles on Unix) and the OS would use it as a disk driver.

      The danger is that .SONY (dot-SONY) is the floppy disk driver. If you happen to name a file that, bad things happen as MacOS mistakes that file as the driver f

  • Why these incompetent cretins have not gone bankrupt already is really beyond me.

    • Invisible hand of the market (AKA Vendor Lock-in)

    • Inertia. Learning a new system is a hassle, so people stick to what they already know. Even if it's crap.

      • It's developer adoption. Mac's lock software vendors into their "App Store" with it's god awful crippling terms of service and use Objective-C for their core API language, Chrome book again locks you into their app store and pumps out hardware that is barely adequate for web surfing. Microsoft is the only major player still agnostic in regards to where you get your software and do I even have to mention how much better MSDN is compared to literally anyone else out there in regards to documentation?

        • No one (for most definitions of no one) uses the Mac App Store, and Macs can still install applications from anywhere, built using any language.

  • Wow (Score:2)

    by sjames ( 1099 )

    The more you think about it, the crazier it gets. The file system will corrupt if you try to READ an invalid file.

    • Re:Wow (Score:5, Informative)

      by alexhs ( 877055 ) on Thursday January 14, 2021 @10:11PM (#60946306) Homepage Journal

      It's not even an invalid file. C:\:$i30:$bitmap is part of the root directory on drive C:. NTFS supports alternative streams, so $i30 describes the actual index of the directory, and the allocation bitmap part of that index. Actually, every time you open C:\, C:\:$i30:$bitmap is opened behind the scene.

      They might not be stupid enough to open the specified stream in read/write mode, but I imagine opening it creates some lock on the stream, which could then somehow cause a desynchronization between $INDEX_ROOT, $INDEX_ALLOCATION and $BITMAP.

      Documentation:
      Archive of the linux-ntfs project, directory page [flatcap.org]
      NTFS streams [microsoft.com]
      Stream types [microsoft.com]

      • Thanks for the info. I was curious how it worked.

        I've read about alternative stream exploits and steganography recently.

      • I would mod you up. It is unclear how long MS knew about it and did nothing. Locks and deadly embraces were taught in 1st year CS. It is unclear why the trace setting also failed. Checking condition codes from a call also in CS102. I bet the Russians reading this are thinking, hmm, this could stop security logging and allow us to do something undetected APT even. Can this be used to hide ftp with solarwinds legacy offerings. An OS that has downtime from logging is dead meat. Source code is also available f

        • Here in my part of the US at least, we call it deadlock instead of deadly embrace.

          It makes it easier to say "this has entered into a deadlock condition", and code using that word. Deadly embrace is more poetic, but a bit harder to work into a logical flow.

          Deadlock detection is a basic part of a lot of operating system design. Either works fine though.

          Ryan Fenton

        • no, its just a flag lock that went wrong, put cold water on your pants checking condition code is easy, not when you have a complex piece of code with 30M lines of code and has legacy code from 1994 still. then its another game entirely. so go back to your books, you have much to learn.

      • Re: (Score:2)

        by Curate ( 783077 )
        Actually C:\:$i30:$bitmap is not opened behind the scene every type you open C:\. There are a few reasons but one reason is because the index bitmap is only needed when allocating or deallocating index blocks. It only comes into play when you are making the directory larger (e.g. creating files) or smaller (e.g. deleting files).
  • Install windows on anything but a C: drive, duh.

    • Re: (Score:2)

      by dryeo ( 100693 )

      Was going to post the same. I've heard that simply not installing on C: prevents most malware attacks as well.

    • The D:\ drive has its own D:\:$i30:$bitmap file.

      • Yes, but all the browser and mail attacks will be targeting C:\:$i30:$bitmap because most Windows computers boot from C: drive. Of course some smart ass will spam all 26 drive letters.

        • It it were me I'd spam everything except drive C:, just to show those idiots who think they're safe because they used D:

        • Yes, but all the browser and mail attacks will be targeting C:\:$i30:$bitmap because most Windows computers boot from C: drive. Of course some smart ass will spam all 26 drive letters.

          Your "yes, but" solution, didn't even make it to the end of your comment before being dismantled?

          Thanks a lot, Helpy Helperton. ;-)

      • Re:Solution is clear. (Score:5, Informative)

        by lent ( 164114 ) on Friday January 15, 2021 @06:04AM (#60947174) Homepage Journal
        https://whereismydata.wordpres... [wordpress.com] "There is one $BitMap per NTFS volume (not per disk). The $BitMap is the 7th entry (MFT record number 6) in the MFT."
        True to NT's was rooted in VAX/VMS. The VAX/VMS FILES-11 disk structure contains the same type of file, named BITMAP.SYS, for each volume. https://www.itec.suny.edu/scsy... [suny.edu]

        Apparently the NT designers felt putting a $ in names was a reasonable way to hide file names and network shares from ordinary list requests. So this latest bug follows an old IIS exploit using $ in a Alternate Data Stream suffix on a URL to the webserver. https://owasp.org/www-communit... [owasp.org]
        The $ will keep the users away from these important, hidden things! Hail the mighty dollar sign! :)
        • Deserves a mod up. The bad is this a LEGACY feature, so MS will be loath to pay for the testing. I wonder if this can be leveraged in the new MS Click-to-run Office baggage recently added. They were too lazy to even check if my old machine had VM support - causing blue-screens.

        • The $ will keep the users away from these important, hidden things! Hail the mighty dollar sign! :)

          Or in the case of *nix, hail the mighty dot!

  • Headache (Score:3)

    by Joe2020 ( 6760092 ) on Thursday January 14, 2021 @09:22PM (#60946150)

    When reading the article and the part on C:\:$i30:$bitmap causes a headache then it's because the brain was formatted with NTFS and is running Windows.

  • Oh please ... (Score:3)

    by PPH ( 736903 ) on Thursday January 14, 2021 @09:36PM (#60946208)

    ... let this icon be a little bitmap of Tux [wikimedia.org].

  • Comments in article say Windows fixes it (Score:5, Interesting)

    by JoeyRox ( 2711699 ) on Thursday January 14, 2021 @10:39PM (#60946414)
    The comment here [bleepingcomputer.com] says:

    "On all three this command returned the result "the file or directory is corrupted and unreadable," with a Security and Maintenance prompt to restart the device. Upon doing so Windows managed to scan and repair the drive successfully on every attempt, usually in a matter of seconds, and have me back at the Windows login screen within a minute. I tested this multiple times on each machine, in some cases running the command in excess of ten times before restarting, and not once did the drives break in such a way that they were unrecoverable. I'm not saying this isn't a problem or its sensationalized, however the testing I did showed no instance of the drives becoming corrupted beyond repair, or something that Windows couldn't fix in the usual way."

    • Comment removed (Score:5, Informative)

      by account_deleted ( 4530225 ) on Thursday January 14, 2021 @11:27PM (#60946528)
      Comment removed based on user account deletion

      • Re: (Score:3)

        by Meneth ( 872868 )
        That implies it ought to affect Windows Vista, 7, 8 and all the Server versions, too. Lots of those systems still around, and most of them aren't receiving or accepting patches anymore.

      • Re:Affects as far back as Windows XP at least (Score:5, Insightful)

        by benjymouse ( 756774 ) on Friday January 15, 2021 @05:45AM (#60947146)

        It appears to be an NTFS based issues as opposed to a Windows 10 thing.
        (Of course, who cares about a dead OS, but it's interesting nonetheless.)

        Yup. It is not even a corruption. Chkdsk does not find and fix any errors.

        I strongly suspect that it is not a corruption at all, but a fault inside NTFS (probably because the access to the alternate datastream will hold a lock), which only flags an operation as faulted, in turn flagging the drive as potentially corrupted.

    • The comment here [bleepingcomputer.com] says: "On all three this command returned the result "the file or directory is corrupted and unreadable," with a Security and Maintenance prompt to restart the device. Upon doing so Windows managed to scan and repair the drive successfully on every attempt, usually in a matter of seconds, and have me back at the Windows login screen within a minute. I tested this multiple times on each machine, in some cases running the command in excess of ten times before restarting, and not once did the drives break in such a way that they were unrecoverable. I'm not saying this isn't a problem or its sensationalized, however the testing I did showed no instance of the drives becoming corrupted beyond repair, or something that Windows couldn't fix in the usual way."

      Try it on multiple builds? Multiple versions of WinXP - Win10? Try it on encrypted drives, whether encrypted with Bitlocker or 3rd party?

      (That last one I'm really curious about.)

      • Re: (Score:2)

        by Calydor ( 739835 )

        I think it depends on whether there is actual corruption or if whatever error is thrown triggers a failsafe to check for corruption just in case - only for that check to come back clean.

    • Re: (Score:3)

      by AmiMoJo ( 196126 )

      I'd love to know why this causes corruption. The path looks like it is accessing some hidden part of the filesystem that normally would not be accessible, maybe something like the block allocation bitmap.

      It should just be a read though, no reason to write to it and corrupt it. I wonder if maybe it's not really corruption, just that when accessed this way Windows marks it as potentially broken and wants to check it, or restore from the backup copy (all important stuff is duplicated in NTFS).

  • Dating myself (Score:5, Funny)

    by Anonymous Coward on Friday January 15, 2021 @12:36AM (#60946706)
    I remember complaining about how horrible Windows security was back around the year 2000. One of our techs said "BS. You couldn't mess up my workstation if you didn't have domain admin privileges". We bet a cup of coffee and the entire support department joined in.

    I hopped on to my Linux box and crafted an HTML email containing a single IMG tag with a SRC attribute containing "c:\con\con". I sent it to our support address. I type pretty fast, so I'm not sure they really saw what I did. It only took a few seconds to compose.

    I said "done" and they looked at me in disbelief, then wondered back to the support area. A few seconds later I hear raised voices shouting at each other and I wonder out. 8 of 9 computers were displaying a nice blue screen...

    8 of the 9 techs owed me a coffee. One tech used Pegasus or something like that. I got chewed out a few hours later because I took down the support office and the techs all had to download a different mail client, sign in to their IMAP box, delete the offending message, and then start using Outlook or Outlook Express again. I forget which one they were using at the time...

    • Re: (Score:3)

      by alexo ( 9335 )

      That only worked on Windows version built on top of DOS (95, 98, possibly ME), which never had any half-decent security, not versions based on the NT kernel.

    • Oh gawd, I had the same experience. Ping of death. "OK, are you sure you've saved your files? All work saved, all programs closed down? Good, let me show you how secure Windows is....".

      • Re: (Score:3, Funny)

        by Moridineas ( 213502 )

        Back in the day my highschool physics teacher was also the network administrator for the school. He let me and another kid install a FreeBSD server (3.0 maybe?) on the school network that was running some version of Netware and an IPX/SPX network. We set the FreeBSD box up to NAT a single IP address to give TCP/IP and internet access to the physics lab. It was pretty cool, and I can't imagine that kind of network access would be allowed anywhere today. (We even got credit for it as an independent study.)

        Any

        • Ah, I remember the days of the Ping of Death. Someone would be being a jackass on IRC or in the lab and you could just PoD them at the worst possible moments. If somebody was a known asshole you'd wait until they were obviously involved in something and hadn't saved and then you BSOD them. Or you just do it randomly.

          But back then around the time Windows 95 came out and all these college students hooked that insecure piece of crap up to their dorm internet connections and left everything wide open it was a

          • Ah, I remember the days of the Ping of Death. Someone would be being a jackass on IRC or in the lab and you could just PoD them at the worst possible moments.

            There was a chat log going around years ago where some script kiddie, armed with his ping of death, was taunting some victim to disclose his IP address. The" victim" replied he was at 127.0.0.1. Script kiddie shortly dropped offline.

            I don't know if it was real or faked, but it was funny as hell anyway.

    • Re: (Score:2)

      by AmiMoJo ( 196126 )

      Outlook had a bug where if any line started with "begin " (two spaces) it would assume everything after that was an attachment. You could troll Outlook users just by making your quote header something like "begin quoting :".

      • You could troll Outlook users just by making your quote header something like "begin quoting :".

        Evidently you foil your attempts by simply downloading a webserver, the slash code, creating a slashdot mirror site, setting up your email server to simply post all emails into the /. comment section and then setup auto email reminders when you need to read a comment.

        Bam problem solved, never see two spaces again. :) - there's two spaces before this smiley.

    • Truly cool story, which I really appreciate, but... With +5 funny and that title I was expecting something completely different... Glad to be proven wrong though.
  • I just tried this on both Windows XP and Windows 10 VMs and both were fine just showing "invalid command.". No drive check on restart either.
    • Most likely because your VM uses VMFS, not NTFS, even if you are accessing a NTFS created volume.

      • Re: (Score:2)

        by dougmc ( 70836 )

        Wouldn't the VM itself (usually) use NTFS within Windows, and therefore be fully susceptible to this? (The exception would be if Windows was installed on a filesystem other than NTFS. FAT32 is still an option for the boot drive, right?)

        VMFS would be the filesystem used by VMware itself, but Windows wouldn't know anything about that -- as far as it's concerned, it's got a hard drive of X GB, and its data partitions are (probably) formatted with NTFS if they're meant to be used with Windows.

        It does look lik

  • why do people insist on calling all bugs zero-day? (Score:4, Informative)

    by hashish ( 62254 ) on Friday January 15, 2021 @04:10AM (#60946966)

    How many mistakes can someone make in the first 4 words "An unpatched zero-day ...."?

    1. An unpatched zero-day what? OK, we know it is an exploit.
    2. If it was a zero-day exploit it would not have 3 publications.
    3. If it was a zero-day exploit it could not be patched by definition.

    • Re:why do people insist on calling all bugs zero-d (Score:4, Informative)

      by ytene ( 4376651 ) on Friday January 15, 2021 @08:04AM (#60947348)
      Spot on. The definition of a "zero day" vulnerability is that the vulnerability has been detected, with an exploit available, before the team responsible for patching or mitigating the vulnerability were made aware that the issue existed. See here. [wikipedia.org]

      In this particular case, as the OP shows, Microsoft have been aware of the issue since at list 2018. Ergo, it cannot by definition be described as a "zero day".

  • Sigh. (Score:3)

    by ledow ( 319597 ) on Friday January 15, 2021 @04:38AM (#60947000) Homepage

    Ah, it's like having file references to CON: or PRT: or LPT: all over again.

  • Not corruption (Score:5, Informative)

    by benjymouse ( 756774 ) on Friday January 15, 2021 @04:43AM (#60947012)

    The bug appears to be that some fault generated within NTFS when executing the command is being wrongly diagnosed by NTFS as drive corruption. The drive is not actually being corrupted. NTFS flags the drive as potentially corrupted and that is what generate the warning to reboot and run chkdsk.

    Several users trying to reproduce this have not been able to actually corrupt the drive, for instance: https://www.bleepingcomputer.c... [bleepingcomputer.com]

    • I tried it on an external flash drive. All I got was an error that the \:$i30:$bitmap file was missing or corrupt. Nothing else. The test files I put on the flash drive were still intact and readable.

  • Just felt appropriate to say, after so many years.

  • Tried on 2004. It went exactly as the video on the article, and after one last reboot the machine was back, as if nothing happened, even with my "bad shortcut" on the desktop.
    Is this "bug" relevant? Anyone else cared enough to just try it?

  • "Corrupts the hard drive" is too strong a term (Score:3, Informative)

    by Bryan Gritton ( 5427430 ) on Friday January 15, 2021 @10:24AM (#60947702)
    I tested this on a spare laptop. The system reported a corruption error and prompted me to reboot, which I did. It ran a disk check when it rebooted, repaired the error, then carried on as if nothing happened. I didn't lose any data.

    It did not "corrupt the hard drive", it created a corrupt file, which the OS easily fixed. Unless there is a more potent way to exploit this, but I think the language used in this article is much stronger than is warranted.

  • Except for all the others.

  • NTFS is pretty brittle if you know where to poke it. What's even worse is that the NTFS driver haven't been updated in years with any improvements and safety/security checks. It was bound to happen people would stumble upon a weakness eventually. It's very easy to corrupt an NTFS volume. If you have raw disk write access there are several ways you can do evil things. Requires around a page if code and rudimentary level of the NTFS and how it works.
    Some defragmentation programs play a dangerous game of using

Slashdot Top Deals

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Close