6 ms·

Does that mean you could send someone a link, or take them to a webpage with a link, to file://killing string and if they click it, their system grinds to a hal

Does that mean you could send someone a link, or take them to a webpage with a link, to file://killing string and if they click it, their system grinds to a halt? Can you DoS a Windows box by trigging an antivirus to try and look for that string? Does it impact Server?

eponeponepon 9y ago
In theory, yes, precisely.
jzig 9y ago
Yes I just confirmed this in a Win7 VM by opening an html file with an img src set that way. It seemed to take a moment for the box to crash so perhaps if you close the window soon enough it might not happen.
- jokr004 9y ago
  I almost guarantee the damage is done immediately once the browser tries to read that file.. The reason it took a moment for your system to crash is because it took a moment for whatever the process was that actually hung to try to read from disk.
- nicktelford 9y ago
  From the article: > [...] the NTFS driver takes out a lock on the file and never releases it. Every subsequent operation sits around waiting for the lock to be released.Forever. This blocks any and all other attempts to access the file system, and so every program will start to hang, rendering the machine unusable until it is rebooted. That delay will likely be how long it takes for the deadlocks to crash the system.
  - xg15 9y ago
    A bug with a walking-ghost phase. How nice.
- pksadiq 9y ago
  Hm.. So a simple javascript that loads the image from specified path would hang M$ windows? Applicable to html emails too in some mail client? We need to find more astonishing ways to hang the windows. Cement and sand should not be the only option.
  - jordache 9y ago
    browsers implement cross domain origin policy to prevent js from accessing the local filesystem. Or did I misunderstand the nature of the Windows bug. It must be trying to read from file:// right?
    - komali2 9y ago
      <img src="c://badfilename"> is enough. You don't need JavaScript.
      - jordache 9y ago
        is this true for even evergreen browsers? Is this true for pages that's hosted in non localhost domain or drag n' dropped into browser from the file explorer? (file:// protocol)
      - deelowe 9y ago
        But you do need the file to be stored locally. I don't think this attack is very serious. Downloading and opening files is already a risky maneuver.
        komali2 9y ago
        My understanding of the article is there isn't a "local file" that matches the name, but the very act of checking for that filename causes the hang. Happy to be corrected.
    - tbodt 9y ago
      heaven praise the same origin policy
- zuppy 9y ago
  Wow, it's like Windows 95 again. I used to crash the computers with \con\con links.
  - DanBC 9y ago
    Or crash IE with <input type crash>
    - azinman2 9y ago
      Wait was that really a thing?
      - marcosdumay 9y ago
        I think all the GP is missing is an '=' sign.
        cesarb 9y ago
        Yes, and that's the trick. The bug happened when IE encountered an "input" element with a "type" attribute which was not followed by an equals sign. "<input type=crash>" wouldn't crash, while "<input type crash>" or "<input type abcdef>" would. Technical explanation: http://www.securityfocus.com/archive/1/319488/30/0/threaded http://www.securityfocus.com/archive/1/319488/30/0/threaded
        jacquesm 9y ago
        And the zero delay animated gif. Instant freeze.
        DanBC 9y ago
        I've never seen that write up before, thank you. It's good.
- jordache 9y ago
  chrome disallows this.
- moyix 9y ago
  To clarify, did you try this with a remotely hosted .html file or one on the local hard drive? Browsers treat this case specially and allow more access to the local filesystem. Putting an html file with an <img src="file:///..."> in it on a remote server should not trigger the vulnerability, if I understand correctly.
  - kauegimenes 9y ago
    This should only work if the .html is located on the local drive. If its hosted you will get a Not allowed to load local resouce error.
shireboy 9y ago
Someone please correct me if I'm wrong, but at least in my testing, IE blocks the file:// request for any non-intranet site. So it won't work with just any webpage.
batat 9y ago
Browser's same-origin policy wolud prevent you from accessing local resources from internet. But this is still pretty exploitable DoS. One could craft a shortcut to "C:\$MFT\non-existing.exe" or bogus "desktop.ini" inside some folder (on network share?) and explorer will crash the system while trying to fetch an icon. I've got a lot of freezes and one BSOD somewhere in ntsf.sys on Windows 7/8.1: ntfs.sys (Ntfs+0x4688) Bugcheck code: 0x24 (0x1904FB, 0xFFFFF88018558398, 0xFFFFF88018557BF0, 0xFFFFF800022D4A77) Error: NTFS_FILE_SYSTEM file path: C:\Windows\system32\drivers\ntfs.sys Here's what process monitor showed me right before BSOD. "Thread exit" from local session manager process looks quite interesting: https://www.dropbox.com/s/99qnpr25nt0tznh/procmon.jpg?raw=1 https://www.dropbox.com/s/99qnpr25nt0tznh/procmon.jpg?raw=1 Exploit PoC: WARNING! Unzipping this archive and/or stepping into unzipped folder likely to crash your system. You have been warned :) https://www.dropbox.com/s/sl5lw6yykvul5b7/ntfs_bug.zip?raw=1 https://www.dropbox.com/s/sl5lw6yykvul5b7/ntfs_bug.zip?raw=1 Bottom line: * Cromium-based browsers seems to download "file.lnk" as "file.download". Wise move, eh? * Dropbox seems to delete shared lnk-files O_o * God bless Sublime Text's session autosave.

eponeponepon 9y ago

In theory, yes, precisely.

jzig 9y ago

Yes I just confirmed this in a Win7 VM by opening an html file with an img src set that way. It seemed to take a moment for the box to crash so perhaps if you close the window soon enough it might not happen.

jokr004 9y ago
I almost guarantee the damage is done immediately once the browser tries to read that file.. The reason it took a moment for your system to crash is because it took a moment for whatever the process was that actually hung to try to read from disk.
nicktelford 9y ago
From the article: > [...] the NTFS driver takes out a lock on the file and never releases it. Every subsequent operation sits around waiting for the lock to be released.Forever. This blocks any and all other attempts to access the file system, and so every program will start to hang, rendering the machine unusable until it is rebooted. That delay will likely be how long it takes for the deadlocks to crash the system.
- xg15 9y ago
  A bug with a walking-ghost phase. How nice.
pksadiq 9y ago
Hm.. So a simple javascript that loads the image from specified path would hang M$ windows? Applicable to html emails too in some mail client? We need to find more astonishing ways to hang the windows. Cement and sand should not be the only option.
- jordache 9y ago
  browsers implement cross domain origin policy to prevent js from accessing the local filesystem. Or did I misunderstand the nature of the Windows bug. It must be trying to read from file:// right?
  - komali2 9y ago
    <img src="c://badfilename"> is enough. You don't need JavaScript.
    - jordache 9y ago
      is this true for even evergreen browsers? Is this true for pages that's hosted in non localhost domain or drag n' dropped into browser from the file explorer? (file:// protocol)
    - deelowe 9y ago
      But you do need the file to be stored locally. I don't think this attack is very serious. Downloading and opening files is already a risky maneuver.
      - komali2 9y ago
        My understanding of the article is there isn't a "local file" that matches the name, but the very act of checking for that filename causes the hang. Happy to be corrected.
  - tbodt 9y ago
    heaven praise the same origin policy
zuppy 9y ago
Wow, it's like Windows 95 again. I used to crash the computers with \con\con links.
- DanBC 9y ago
  Or crash IE with <input type crash>
  - azinman2 9y ago
    Wait was that really a thing?
    - marcosdumay 9y ago
      I think all the GP is missing is an '=' sign.
      - cesarb 9y ago
        Yes, and that's the trick. The bug happened when IE encountered an "input" element with a "type" attribute which was not followed by an equals sign. "<input type=crash>" wouldn't crash, while "<input type crash>" or "<input type abcdef>" would. Technical explanation: http://www.securityfocus.com/archive/1/319488/30/0/threaded http://www.securityfocus.com/archive/1/319488/30/0/threaded
        jacquesm 9y ago
        And the zero delay animated gif. Instant freeze.
        DanBC 9y ago
        I've never seen that write up before, thank you. It's good.
jordache 9y ago
chrome disallows this.
moyix 9y ago
To clarify, did you try this with a remotely hosted .html file or one on the local hard drive? Browsers treat this case specially and allow more access to the local filesystem. Putting an html file with an <img src="file:///..."> in it on a remote server should not trigger the vulnerability, if I understand correctly.
- kauegimenes 9y ago
  This should only work if the .html is located on the local drive. If its hosted you will get a Not allowed to load local resouce error.

shireboy 9y ago

Someone please correct me if I'm wrong, but at least in my testing, IE blocks the file:// request for any non-intranet site. So it won't work with just any webpage.

batat 9y ago

Browser's same-origin policy wolud prevent you from accessing local resources from internet. But this is still pretty exploitable DoS. One could craft a shortcut to "C:\$MFT\non-existing.exe" or bogus "desktop.ini" inside some folder (on network share?) and explorer will crash the system while trying to fetch an icon. I've got a lot of freezes and one BSOD somewhere in ntsf.sys on Windows 7/8.1: ntfs.sys (Ntfs+0x4688) Bugcheck code: 0x24 (0x1904FB, 0xFFFFF88018558398, 0xFFFFF88018557BF0, 0xFFFFF800022D4A77) Error: NTFS_FILE_SYSTEM file path: C:\Windows\system32\drivers\ntfs.sys Here's what process monitor showed me right before BSOD. "Thread exit" from local session manager process looks quite interesting: https://www.dropbox.com/s/99qnpr25nt0tznh/procmon.jpg?raw=1 https://www.dropbox.com/s/99qnpr25nt0tznh/procmon.jpg?raw=1 Exploit PoC: WARNING! Unzipping this archive and/or stepping into unzipped folder likely to crash your system. You have been warned :) https://www.dropbox.com/s/sl5lw6yykvul5b7/ntfs_bug.zip?raw=1 https://www.dropbox.com/s/sl5lw6yykvul5b7/ntfs_bug.zip?raw=1 Bottom line: * Cromium-based browsers seems to download "file.lnk" as "file.download". Wise move, eh? * Dropbox seems to delete shared lnk-files O_o * God bless Sublime Text's session autosave.