Firefox bug – Authentication Modals in Loop

Malicious sites take advantage of many bugs to trap users and trick them into handing over sensitive data. Firefox has one that prevents users from leaving a site (or the browser itself) with authentication modals in loop.

This is a fairly old bug — one that users first reported to Firefox collaborators in April 2007. It consists in an iframe making an HTTP authentication request as soon as the user arrives in the page. If the user dismisses it, another one pops up immediately afterwards.

Why Does It Happen?

In Firefox, authentication modals are window-based, meaning they prevent the user from doing anything before dealing with them. Of course, this is not a problem in legitimate pages that require you to log in before accessing their content.

However, if any page sends HTTP authentication requests to another domain in a loop, it will effectively trap the user in it. The only solution is to close the window in unusual ways, such as killing the Firefox process.

Some workarounds do exist, such as the one described by a collaborator in the report page: “Put mouse over tab close button” and “press escape (ESC) immediately followed by left mouse button (LMB) click”.

This is somewhat clumsy, though, and as the own collaborator point out, “depending on speed of the server you may need to try a couple times”. It would certainly be better if the issue was fixed once and for all.

Why Hasn’t It Been Fixed?

Both Edge and Chrome have dealt with this problem in different ways: in Edge, the time between one authentication request and the next is enough for the user to close the tab. In Chrome, the modal can’t stop the user from simply closing the tab.

Turning an HTTP authentication request into a tab based modal would solve the problem. And, indeed, some have discussed the idea. Looking at this this way, it is certainly odd that Mozilla engineers have left this issue unfixed after all this time.

However and of course, Mozilla is an open source project. As such, the changes in priority and assignment are visible to anyone. However, problems like these do happen in any project, and Microsoft has issues with Internet Explorer security to this day.

Whenever a bug isn’t readily fixed, it is usually a mix of the following factors:

• Significant time investment, technical complexity and difficult trade-offs
• Lack of resources
• Difficulty to compromise in a non-perfect solution
• Opposing options for a decision in a stalemate

Then, it’s comprehensible that Mozilla would face more hardships to solve a bug like these as years go by. Priorities change all the time and, as the browser’s very architecture changes, it’s hard to keep track of the possible solutions and their consequences.

Firefox and Web Security Today

In the wake of Edge’s rebirth as Chromium-based, there are now only three major browser engines — Blink, Gecko and WebKit. This sheds light on the importance of having more security options for browsing and restricting the activity of malware creators.

It’s certainly concerning that a bug allows a page to cripple the user’s navigation. What’s more, this kind of trap feels very urgent to the user — making it more likely for the unsuspecting ones to fall for it.

As a collaborator pointed out, “a maximized window with a attacker-controlled message is shown, and it cannot be closed, potentially giving the user a feeling of loss of control, contributing to effectiveness of the phishing message presented.”

Some examples of sites that exploit this bug are ad farms, support scams or sites that offer fake software updates.

---

Categories: News