899718 - FIXUP_FLAGS_MAKE_ALTERNATE_URI in nsIURIFixup violates RFC 3986

Status: UNCONFIRMED

(Firefox :: Menus, defect)

Description

[JDev]

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

I was experiencing a cache issue whereby some images do not display properly until the cache is cleared.  In diagnosing the issue I selected "view image" before the page finished loading and was taken to an entirely different site instead of to the image.

1) Went to http://www.trueachievements.com/kingdoms-of-amalur-reckoning-walkthrough.htm
2) Noticed the images under "gamers involved" were not loading properly.  
3) Right clicked and selected view image (must be done before image is loaded or page finishes rendering)

At this point the //Imagestore/thumbs/0000310200/310286.jpg was re-written and the //Imagestore/ was incorrectly interpreted as the domain.  Doing the exact same behaviour with a successfully loaded image works correctly.

I am marking this as a security issue (though at best it's a very very minor one) because this could be used to enable passive phishing attacks where the person believes they are still on the site they entered but have in fact been redirected elsewhere though fault of their own.  *Note this is not a Google "I'm feeling lucky" redirect either - double checked that before posting.

Similar bug https://bugzilla.mozilla.org/show_bug.cgi?id=317056


Actual results:

Result: I was taken to http://www.imagestore.com/thumbs/0000310200/310286.jpg


Expected results:

Intended result: I should have been taken to http://www.trueachievements.com/Imagestore/thumbs/0000310200/310286.jpg

Comment 1

[Andrew McCreight [:mccr8]]

This sounds kind of like a document navigation issue, though maybe it is a problem with whatever is storing images.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Um... no, sounds like a "ui is getting a bogus string and then passing it to people" issue to me.

Comment 3

[Daniel Veditz [:dveditz]]

If the URL was really "//Imagestore/thumbs/0000310200/310286.jpg" then that's a scheme-relative link to the Imagestore domain.

I can't reproduce so maybe we'll try with a throttled huge image to see. Was the site wrong, and sending a relative link with an extra slash? Or is there somewhere we're doing that?

Comment 4

[JDev]

After reading http://www.ietf.org/rfc/rfc1808.txt I agree, the //Imagestore/ scheme should resolve image store as the net_loc.  The problem derives from Firefox's attempt to guess at possible corrections to the net_loc if it fails to resolve.  

If someone were to include an extra slash in a link it should fail to resolve and display the appropriate message.  By guessing at the intended suffix (.com/.net/etc) it's opening up this phishing vector unnecessarily.

This guessing feature was also disabled for <script> tags to prevent scripts from other sites from being loaded accidentally.  The same ought to be done for all tags and guessing only be done in the address bar or removed entirely.

Comment 5

[Daniel Veditz [:dveditz]]

Today the images on that page look like

<img class="smallicon" title="PuckJunkie" alt="PuckJunkie" src="http://im2.trueachievements.com/imagestore/thumbs/0000310200/310286.jpg"></img>

Seems to be the same thumbnail (visually, and same filename) as the www. link in comment 0. There's no way we could "correct" or truncate either link to //Imagestore/, the page must have contained that link for that period of time.

Was it really capitalized? We wouldn't have changed it from imagestore to Imagestore either, which also seems to point to the site being at fault. When sites are loaded we do the opposite, in fact, canonicalize to lowercase.

I'm convinced you hit a temporary glitch with the site and not a security bug we need to resolve.

Some people complain that we attempt URL rewrites at all, and that's a valid opinion, but that's a design decision that needs to be hashed out in discussions before we can file a change ticket.

Comment 6

[JDev]

As stated in comment 4, the site corrected the error.  You appear to have gotten the problem backwards as //Imagestore/ was being converted to www.imagestore.com

The problem lies in the fact that an attacker could look for common directory names, register the .com and sit back and wait for this type of extra slash error to occur on *any* domain.  Once it does an automated script could then scrape the target site, duplicate the look and prompt for login details.  In theory (I have not tested yet) any element with an src/href would be vulnerable (except script tags)and while the address may change there would be little else to indicate you've moved to a new site.

Comment 7

[JDev]

oops!  I should say as was supposed to have been stated in comment 4... I guess I edited that part out before submitting that comment lol

Comment 8

[JDev]

I gave this the time it deserved and did a proper reading of the standards (note I did not notice RFC 1808 was obsoleted by RFC 3986 at the time).  In the case above, while the site was in error with its coding, the implications do not change.  There are several problems, first //foo/ may not mean HTTP scheme, to assume so is bad.  Second, assuming //foo/ is part of the http scheme, // denotes the beginning of an authority, / the end of the authority.  foo would be the authority which comprises possible user details, a host, and a port number.  Being that foo falls under the "host" portion section 3.2.2 applies

3.2.2 states that "The presence of a host subcomponent within a URI does not imply that the scheme requires access to the given host on the Internet"

By rewriting //foo/ to //www.foo.com/ it is taking //foo/ to imply a host on the internet when it maybe a host found locally such as, //localhost/.  While there is an exception made for //localhost/ it is a valid form for other host names which are not found on the internet. 

Further, this could be used (intentionally or accidentally) to perform a denial of service attack against an innocent site.  A single errant / on a relative image link from google.com (using src="//images/...") could unintentionally take down images.com or similar.  In addition there's a privacy issue because if a //xxxxxxx/ format is being used with a modified local DNS it could resolve properly when on a given network but then expose data when the system is switched to a different network.

FIXUP_FLAGS_MAKE_ALTERNATE_URI's rewriting of hosts to .com/.net/etc should be removed entirely due to the reasons expressed in here (phishing/denial/pivacy/RFC violation) and because it's of extremely limited value with the number of TLDs available now.

Comment 9

[Masatoshi Kimura [:emk]]

(In reply to JMJimmy from comment #8)
> A single errant / on a
> relative image link from google.com (using src="//images/...") could
> unintentionally take down images.com or similar.

nsIURIFixup is not used for URLs in the markups. It is only used for the location bar.

Comment 10

[JDev]

There's a second method doing the same function?  If so could you point me to it?  Both ways it's still applicable.