5 ms·

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 c

• 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
    • blockoperation 9y ago
      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.
• 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.