1368682 - NTFS MFT Bug Reported Causes Hang

Status: NEW

(Core :: Networking: File, defect, P3)

Description

[quality+bugzilla]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170518000419

Steps to reproduce:

According to multiple reports, in certain circumstances, using $MFT as part of a pathname can hang Windows 7/8.1 when using Firefox.

According to the Bleeping Computer article (below) the bug can even be triggered when "the path is secretly loaded in the background of a web page, as an image's source URL."

Furthermore, the article states: "Bleeping Computer confirmed that the $MFT bug causes a Windows 7 installation to hang via Internet Explorer and Firefox."

See:
https://habrahabr.ru/company/aladdinrd/blog/329166/
https://www.bleepingcomputer.com/news/microsoft/filesystem-bug-hangs-or-crashes-windows-7-and-windows-8-1/
https://arstechnica.co.uk/information-technology/2017/05/in-a-throwback-to-the-90s-ntfs-bug-lets-anyone-hang-or-crash-windows-7-8-1/

Comment 1

[Andrew McCreight [:mccr8]]

Jim, do you have any idea of what to do with this bug that seems to involve trying to load a certain magic path on Windows?

Comment 2

[Nathan Froyd [:froydnj]]

(In reply to Andrew McCreight [:mccr8] from comment #1)
> Jim, do you have any idea of what to do with this bug that seems to involve
> trying to load a certain magic path on Windows?

Maybe we should try to disallow magic paths in the file:// loader somehow?

Comment 3

[Jim Mathies [:jimm]]

(In reply to Nathan Froyd [:froydnj] from comment #2)
> (In reply to Andrew McCreight [:mccr8] from comment #1)
> > Jim, do you have any idea of what to do with this bug that seems to involve
> > trying to load a certain magic path on Windows?
> 
> Maybe we should try to disallow magic paths in the file:// loader somehow?

This seems reasonable for a one-off path like this.

Comment 4

[Andrew McCreight [:mccr8]]

I tried searching in the Chrome source code for MFT or $MFT to see what they might be doing for filtering, but there were too many results. I dug through a few of them and didn't see anything relevant.

Comment 5

[Daniel Veditz [:dveditz]]

All those links are public so we can unhide this bug.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> when "the path is secretly loaded in the background of a web page, as an image's source URL."

A web page shouldn't be able to use a file:// URL as an image's source URL.  Certainly not to the point where we asyncOpen the channel (and hence try to open the file).  This is in place precisely because of problems like this.

Is just creating an nsIURI for such a string enough to trigger the problem?  That is, it's enough to try to stat the file, you don't have to try to open it?

Comment 7

[Jim Mathies [:jimm]]

Attachment: don't open this as a html page in Firefox.txt

Comment 8

[Jim Mathies [:jimm]]

[Tracking Requested - why for this release]:(In reply to Jim Mathies [:jimm] from comment #7)
> Created attachment 8873158 [details]
> don't open this as a html page in Firefox.txt

Interesting. This appears to work for content saved to a local file. However I can't repo using remote content. It's possible the people who wrote that article tested local content as well.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> This appears to work for content saved to a local file.

Well, right, because local files can load other local files.  That's true even in Chrome, for something like an <img> load.

> However I can't repo using remote content.

OK, that's good.

> It's possible the people who wrote that article tested local content as well.

True, though if they're going to claim it's a problem for "web pages"...

Anyway, we could certainly try adding a check for this in filechannel.  

One other note: I checked for '$MFT' in Blink source code, and it's not there.  It's possible that it's their sandbox preventing it from being opened, or that the tests for Chrome were _not_ done with a local file or something.  Would be good to confirm what the actual Chrome behavior is here.

Comment 10

[Boris Zbarsky [:bzbarsky]]

So is this actually a problem for non-file:// URIs?  Because file:// URIs can also do the con/con thing, etc....

Comment 11

[Jim Mathies [:jimm]]

(In reply to Boris Zbarsky [:bz] (if a patch has no decent message, automatic r-) from comment #10)
> So is this actually a problem for non-file:// URIs?  Because file:// URIs
> can also do the con/con thing, etc....

Not sure what you mean by non-file:// urls, can you provide an example? I guess this might trigger if having this special string token embedded in a web based directory path somehow translates into a local directory name in a service of some type, like the disk cache.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> Not sure what you mean by non-file:// urls

I mean a web page loaded from some URL that does not start with "file://".

Comment 13

[quality+bugzilla]

Perhaps someone can contact the authors of the original reports, and find out what testing they performed to come to their conclusions.

Also, does this need to be assigned to someone?

Comment 14

[Jim Mathies [:jimm]]

(In reply to Boris Zbarsky [:bz] (if a patch has no decent message, automatic r-) from comment #12)
> > Not sure what you mean by non-file:// urls
> 
> I mean a web page loaded from some URL that does not start with "file://".

I already mentioned this doesn't reproduce for remote content in comment 8.

Comment 15

[quality+bugzilla]

I recommend someone contact the authors of the published articles, to determine if they found something that is being overlooked here.

At the least, if their reporting is erroneous, they should be asked to modify their published articles to accurately reflect the extent of this issue.