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?
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:
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.
> [...] 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.
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.
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.
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
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?
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.
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)
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.
