As requested at https://bugzilla.mozilla.org/show_bug.cgi?id=377496

re-entering the bug here.

Sequence of events is:

1. Bing ad for common term such as "bug report" sends user to
   http://shop.frankfurt-airport.store

2. Redirects to attack site.

3. Page in attachment appears. Obvious phishing attack coupled with denial of service attack.

4. Unable to dismiss basic authentication prompt. Unable to stop page. Unable to close browser. Ubuntu Linux 18.04 begins thrashing with heavy disk I/O.

5. Finally was able to open a terminal window, which took many minutes to open, ran "top" to find Firefox process, killed Firefox. System returned to normal.

Per request, attack site was: " http://165.22.224.156". Use caution.

The website in question seems unreachable to me. Do you still have the source by any chance? Technically the page shouldn't be able to open more than 2 auth prompts, but maybe they found a way around this restriction. Unfortunately there's no way to tell without the source. Did you try cancelling the prompt?

Yes, I tried cancelling the prompt. Cancel seemed to have no effect, even if repeated. But by that time the browser was suffering from a DOS attack and couldn't seem to do anything, including close.

It looks like the attack site has gone down.

Actual attack URL after redirect: http://165.22.224.156/cmspr0mt-redrt-handlr-sctn03dsk-logsctor-er0rr/ffxercx-np/

But it no longer responds to either Firefox or curl.

Ok, that's too bad. Without the code we're somewhat left to guess what's happening here.

In general I'm afraid that resource exhaustion + window modals will continue to be a somewhat viable attack even if the rate-limit was working. We're currently working on a tab modal prompt that should hopefully put an end to this for good.

Paul, can you do me the favor and check whether our rate-limit measures for prompts can be circumvented using IP-address hosts? It could be because we're reducing to eTLD+1 or something. So far this is my only idea about it.

Thanks!

Sorry I didn't catch the page source before it went offline. Right now, the IP address doesn't even answer pings.

This is the first time I've seen a web page able to quickly stall out not just Firefox but the Linux system. It took me 15 minutes to get a terminal window open and kill the process. I've seen resource-consuming attacks before, but this one uses up all available memory within seconds and forces paging.

Some ordinary shutdown user interface action needs to continue to work under extreme overload. Closing the window should work, and it doesn't. Clicking on the "stop web page" X should work, and it doesn't. Clicking on the "Stop It" button should work, and it doesn't. That's not good.

I've tested the rate limiting with an IP-address host. It works as expected and only allows two prompts. I've also tested redirects between subdomains and two different domains (and IPs), properly rate limited in both cases.

The IP address belongs to DigitalOcean, the current server under that address only accepts ssh connections. The original "Droplet" has most likely been destroyed and the new one could be assigned to a new customer.

Thanks, but unfortunately that means we don't really have clue what's going on there :/

Calling this fixed by the new auth modal prompts.