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

RESOLVED FIXED

Status

()

P5
normal
RESOLVED FIXED
2 years ago
11 months ago

People

(Reporter: hanno, Unassigned)

Tracking

({csectype-spoof, nightly-community})

Trunk
csectype-spoof, nightly-community
Points:
---
Dependency tree / graph
Bug Flags:
sec-bounty -

Firefox Tracking Flags

(firefox-esr52 wontfix, firefox55 wontfix, firefox56 wontfix, firefox57 fix-optional, firefox58 affected)

Details

(Whiteboard: [necko-would-take])

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
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 3

2 years ago
(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.
Group: firefox-core-security → core-security
Component: Security → Networking: FTP
Flags: needinfo?(honzab.moz)
Product: Firefox → Core
(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.
Flags: needinfo?(honzab.moz)
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.
Group: core-security
Depends on: 1357835
Keywords: csectype-spoof
(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
Whiteboard: [necko-would-take]
(Reporter)

Comment 8

2 years ago
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.
(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.
status-firefox55: --- → affected
status-firefox56: --- → affected
status-firefox57: --- → affected
status-firefox58: --- → affected
status-firefox-esr52: --- → affected
tracking-firefox57: --- → ?
Keywords: nightly-community
OS: Unspecified → All
Hardware: Unspecified → All
Version: unspecified → Trunk
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!
Flags: needinfo?(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)
Flags: needinfo?(dveditz)
(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
status-firefox55: affected → wontfix
status-firefox56: affected → wontfix
status-firefox57: affected → fix-optional
status-firefox-esr52: affected → wontfix
tracking-firefox57: ? → ---
Depends on: 1404744
See Also: bug 1404744
(Reporter)

Comment 13

a year ago
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

a year ago
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).
I am working on bug 1404744, which should fix this whole class of FTP related issue.
Fixed via https://bugzilla.mozilla.org/show_bug.cgi?id=1404744, as Tom says.
Status: NEW → RESOLVED
Last Resolved: a year ago
Flags: sec-bounty?
Resolution: --- → FIXED
(Reporter)

Comment 17

11 months ago
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.
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.
Flags: sec-bounty? → sec-bounty-
You need to log in before you can comment on or make changes to this bug.