1361848 - ftp allows bypassing cross site authentication (XSA) warning on login forms

Status: RESOLVED FIXED

(Core Graveyard :: Networking: FTP, defect, P5)

Description

[Hanno Boeck]

To understand this bug it's important to understand what an XSA-attack is. It's originally been described by Joachim Breitner [1]:

If a site allows a user to include images from foreign hosts (e.g. common in forums) this can be used for an attack to steal login information. The attacker includes an image on a host he controls. Later he switches on HTTP basic authentication on that host. People visiting that site will get a login form from the browser. The attacker now can just collect all login credentials entered into that form.

To mitigate this attack Firefox shows a warning ("WARNING: Your password will not be sent to the website you are currently visiting!"). However the identical attack can also be launched using the ftp:// protocol - and this bypasses the warning. I attached screenshots of both scenarios.

A note on fixing this: The "obvious" fix would be to show the same warning for the ftp protocol. But I'd propose something different: Just don't allow authentication logins for images or other third party content on sites. I would assume that if such an attack would be launched many users may not read through the warning. And I see no legit reason to have an image included in a webpage to be authenticated separately from the webpage itself. (Chrome doesn't allow http auth or ftp auth for images included via the img tag.)


[1] http://www.joachim-breitner.de/blog/56-Like_XSS,_just_simpler_and_harder_to_prevent__The_Cross_Site_Auth_(XSA)_Attack

Comment 1

[Hanno Boeck]

Attachment: Cross site authentication with HTTPS warning

Comment 2

[Hanno Boeck]

Attachment: Cross site authentication with FTP (no warning)

Comment 3

[:Gijs (out for now; he/him)]

(In reply to Hanno Boeck from comment #0)
> A note on fixing this: The "obvious" fix would be to show the same warning
> for the ftp protocol.

I'm not sure why we don't. Honza?

> But I'd propose something different: Just don't allow
> authentication logins for images or other third party content on sites. I
> would assume that if such an attack would be launched many users may not
> read through the warning. And I see no legit reason to have an image
> included in a webpage to be authenticated separately from the webpage
> itself. (Chrome doesn't allow http auth or ftp auth for images included via
> the img tag.)

This is bug 1357835 and/or bug 647010. You seeing "no legit reason" unfortunately didn't prevent us from running into the realities of the internet when we tried to ship such a change in Firefox 40 (several years ago now) and had to back it out because omgbreakage. We're re-evaluating, again, in bug 1357835. I would just dupe this and open it up, but I think the ftp: thing probably deserves some more scrutiny.

Comment 4

[Honza Bambas (:mayhemer)]

(In reply to :Gijs from comment #3)
> (In reply to Hanno Boeck from comment #0)
> > A note on fixing this: The "obvious" fix would be to show the same warning
> > for the ftp protocol.
> 
> I'm not sure why we don't. Honza?

The reason might be (not an excuse) that we don't maintain the FTP code almost at all.  There were plans in the past to remove it completely and hand it to an add-on.  But nothing like that happened.  

This is a security risk, yes.  But not worse than what we do with HTTP these days.

> 
> > But I'd propose something different: Just don't allow
> > authentication logins for images or other third party content on sites. I
> > would assume that if such an attack would be launched many users may not
> > read through the warning. And I see no legit reason to have an image
> > included in a webpage to be authenticated separately from the webpage
> > itself. (Chrome doesn't allow http auth or ftp auth for images included via
> > the img tag.)
> 
> This is bug 1357835 and/or bug 647010. You seeing "no legit reason"
> unfortunately didn't prevent us from running into the realities of the
> internet when we tried to ship such a change in Firefox 40 (several years
> ago now) and had to back it out because omgbreakage. We're re-evaluating,
> again, in bug 1357835. I would just dupe this and open it up, but I think
> the ftp: thing probably deserves some more scrutiny.

I would agree to open and dup to 1357835.

Comment 5

[Daniel Veditz [:dveditz]]

Agreeing with Honza, except I want to make this "depend on" bug 1357835 rather than dupe it because I'm not confident an HTTP fix in that bug will actually fix FTP, just as the auth warning didn't make it over.

Comment 6

[Honza Bambas (:mayhemer)]

(In reply to Daniel Veditz [:dveditz] from comment #5)
> rather than dupe it because I'm not confident an HTTP fix in that bug will

It wont just that.  The ftp code needs to be updated.  nsFtpState::S_user() needs to check NS_SecurityCompareURIs of the loading URI and the top-level URI and on mismatch set promptFlags |= nsIAuthInformation::CROSS_ORIGIN_SUB_RESOURCE.

See also for how we do it in http
https://bugzilla.mozilla.org/attachment.cgi?id=8760157&action=diff#a/netwerk/protocol/http/nsHttpChannelAuthProvider.cpp_sec5
https://bugzilla.mozilla.org/attachment.cgi?id=8760157&action=diff#a/netwerk/protocol/http/nsHttpChannelAuthProvider.cpp_sec6

Comment 7

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 8

[Hanno Boeck]

Given that there's no visible activity on fixing this and it's been open several months I intend to disclose this bug within a week.

Comment 9

[Darkspirit]

(I'm just a Nightly user/community member.)

[Tracking Requested - why for this release]:
A Firefox 57 user could visit a forum, get a username/password prompt (attachment 8864303 [details]) and thinks he has to enter his forum login credentials, although it's an FTP login form of an external image.

If that external image had come via HTTP(S) with HTTP Basic Auth he would have been explicitly warned (attachment 8864302 [details]) that this login form is not for the website/forum he is currently visiting. 

P.S. The reporter is an IT security journalist.

Comment 10

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hi Dan, is this a must fix for 57? If not, given that this was tagged a P5, I am inclined to wontfix this for 57 as I doubt we will get around to it. Thanks!

Comment 11

[Daniel Veditz [:dveditz]]

It's not a blocker for 57. Observant users will notice that ftp://randomsite is not the site they're on. Unobservant users may well fall for the phish despite the warning. Not a reason to ignore the bug--a warning would surely help protect at least some people--but it's not an urgent blocker.

I'm actually more interested in bug 1404744 (as are Chrome folks). FTP is fine, but not mixed with http.

(see also bug 1174462 which wanted to remove FTP support entirely)

Comment 12

[Darkspirit]

(In reply to Daniel Veditz [:dveditz] from comment #11)
> I'm actually more interested in bug 1404744 (as are Chrome folks). FTP is fine, but not mixed with http.

I think Hanno would be happy about it and we could prevent bad press.

(as suggested in comment 0: ideally also bug 647010 in the future (network.auth.subresource-http-auth-allow;1) which got backed out 2 years ago:
https://www.fxsitecompat.com/en-CA/docs/2015/http-auth-dialog-can-no-longer-be-triggered-by-cross-origin-resources/ )

> (see also bug 1174462 which wanted to remove FTP support entirely)

intermediate step: bug 1374114

Comment 13

[Hanno Boeck]

I blogged about this:
https://blog.hboeck.de/archives/891-Some-minor-Security-Quirks-in-Firefox.html

Please note there's also an interesting comment below the blogpost that points out using HTTP redirects this vulnerability is more severe than I thought. It allows potentially exploiting this on webpages that only allow http/https image includes.

Comment 14

[rugk]

Any news here? We are already at Firefox 59 stable and this is still not fixed (despite being more or less intended to fix in FF 57, as it seems).

Comment 15

[Tom S [:evilpie]]

I am working on bug 1404744, which should fix this whole class of FTP related issue.

Comment 16

[Frederik Braun [:freddy]]

Fixed via https://bugzilla.mozilla.org/show_bug.cgi?id=1404744, as Tom says.

Comment 17

[Hanno Boeck]

FWIW here's a poc showing this issue on twitter:
https://twitter.com/xsamaster/status/980447955692998657

When I originally reported this I was not aware of this vector where major social networks allow you to control the content of an iframe. I believe makes this bug a bit more serious.

Comment 18

[Daniel Veditz [:dveditz]]

I don't see how that makes the problem any worse? either people will read the text (and not log in) or they'll say "wow, this site never does that" and mostly not log in. Even the form WITH the warning (and this bug is that the FTP version ought to have that) isn't going to stop people who aren't paying attention.

for the record, what I see with that tweet is a test.mecronome.de panel with a play button, that loads an HTML page that has an ftp image. The twitter link contains

  <meta name="twitter:card" content="player" />
  <meta name="twitter:title" content="Let's grab your login credentials via FTP." />
  <meta name="twitter:player" content="https://test.mecronome.de/ftplogin/container.html" />

and then container.html is the one with the <img> tag.