Hacker News Reader

Comment by Nexxxeh | Hacker News Reader

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?

View on HN

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

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

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.

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.

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.

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.

A bug with a walking-ghost phase. How nice.

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.

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?

<img src="c://badfilename"> is enough. You don't need JavaScript.

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)

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.

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.

heaven praise the same origin policy

Resources/frames/XHRs/etc from 'file://' might be blocked, but what about top-level redirects?

At the very least, user-initiated top-level navigations should bypass any policies. If you're out to cause mischief, you could just link to the dodgy path on forums/comments/etc – there'll always be people out there who are careless and/or clueless enough to click on it.

Wow, it's like Windows 95 again. I used to crash the computers with \con\con links.

Or crash IE with <input type crash>

Wait was that really a thing?

I think all the GP is missing is an '=' sign.

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

I've never seen that write up before, thank you. It's good.

And the zero delay animated gif. Instant freeze.

chrome disallows this.

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.

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.

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.

In theory, yes, precisely.

Reply on news.ycombinator.com