No TCP connection limit (per origin) for ftp:// URLs
Reported by
ro...@netsecurity.tech,
Aug 23 2016
|
|||||||
Issue descriptionVULNERABILITY DETAILS Most browsers allow for a limitation on FTP connections made by the user. However this is not the case in Chrome. This can lead to serious vulnerability because a small javascript can be used to DOS a Apache Server. This exploitation was tested on a website that was own by me and was running updated Apache version. Same exploit was tested on firefox and was unsuccessful in running. VERSION Chrome Version: Version 52.0.2743.116 m Operating System: Windows 10 REPRODUCTION CASE var domain = 'example.com'; for( i = 0; i < 768; ++i ) { var img = document.createElement('img'); img.setAttribute('src', 'ftp://' + domain + ':80/image' + new Date().getTime() + i ); document.body.appendChild(img); } Paste this script on the developer console and run. Replace the example.com with a domain that is running a Apache server. This bug is reported to chrome rather than to Apache because this only seems to work with Google Chrome which indicates that there is a fault in the chrome.
,
Aug 24 2016
This isn't a DoS of Chrome, but leveraging Chrome to DoS a web server. I found https://github.com/anttiviljami/dos-with-js-in-the-browser, which seems related.
,
Aug 25 2016
Seems like a team member of ours released it once it was discovered.
,
Aug 25 2016
Eric, any opinions here. I don't see how Chrome can prevent this in any way or how Firefox is preventing this currently.
,
Aug 25 2016
I am sure Firefox has some security enabled because when I tried the same thing it did not work. First we thought this to be an apache bug but because this was only reproducible with Chrome we decided to report it here. Also do you want us to remove the github post or make it private for time being?
,
Aug 25 2016
It looks like Chrome's FTP code doesn't go through the same socket pool mechanism as HTTP. So whereas HTTP is quite limited in the number of parallel TCP connections that will be opened per origin (the source of frequent complaints in fact...), the FTP code (from my quick read) effectively has no limit on the number of TCP connections that will be opened per origin. I agree with the reporter that there should be _some_ limit for FTP transactions. Whether that be per origin, global, or both (or sharing quota with http pool) So yes, this is something we should fix. As far as this being a "security" bug, I am not convinced: Certainly this is a very convenient way to open many TCP sockets to a host, but it is not the only one. For instance WebSockets similarly don't follow the same HTTP socket pool limits (intentional feature), so WebScokets could be used in a similar fashion to mount an attack, modulo perhaps some same-origin issues. Another approach if you control a DNS resolver would be to make the client issue requests to a bunch of different hosts, but have them all map to the same destination IP, and you could also bypass the per-domain limit. As a separate side note, I wonder if supporting FTP over port 80 is actually necessary? (If we could reject ports 80 and 443 for ftp it would also break the repro case)...
,
Aug 25 2016
Removing security tags based on c#6.
,
Aug 25 2016
,
Aug 28 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by infe...@chromium.org
, Aug 23 2016